ift ift http://ift.wiki.uib.no/Main_Page MediaWiki 1.39.6 first-letter Media Special Talk User User talk ift ift talk File File talk MediaWiki MediaWiki talk Template Template talk Help Help talk Category Category talk Form Form talk Widget Widget talk 0 1 1 2009-02-12T14:36:43Z MediaWiki default 0 wikitext text/x-wiki <big>'''MediaWiki has been successfully installed.'''</big> Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 08fc850f2898611c250d639e30f69532b5a016f8 2 2009-02-13T09:32:00Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 9a1eb207daacccd2dfb88dc99c33298e41e6b100 3 2009-02-18T09:47:35Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [Experimental Nuclear Physics group] Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 5e91625d51257cd55022e2bf6ea3c453342e9d30 4 2009-02-18T09:47:58Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Experimental Nuclear Physics group]] Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 8d4f74843237377a8e58d1c4b58b70ed6a3a110f 12 2009-02-18T10:05:53Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Space Physics group]] Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] caa6a5f4aa7f9a3e178c02a0e803a3ae5472e5b6 19 2009-02-18T10:23:11Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 011171ab8ea50902aa4375c1a391badf300c202a 20 2009-02-18T10:27:02Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] ebd9b3886ef17083fa97d3ddaecac76032646e95 21 2009-02-18T10:41:45Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] --- == Getting started == Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 8127c63e4d0167c5b0653f80b136bd4f86749673 0 2 5 2009-02-18T09:48:34Z Nfyku 4 New page: == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the Universi... wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- * [[CERN Schedule]] Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[PHOS PVSS panels]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Tips & Tricks corner]] * [[Intern]] * [[ALICE Gallery for pictures, plots, etc...]] <center>[[Image:alice.gif]]</center> 95da02ce9f4902f63303f9819b9474160fb34bb0 18 2009-02-18T10:10:02Z Nfyku 4 wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[PHOS PVSS panels]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Tips & Tricks corner]] <center>[[Image:alice.gif]]</center> f88d17b0707b5ea2e67c97d49f84321e08274190 0 3 6 2009-02-18T09:50:25Z Nfyku 4 New page: == Overview == The Busy Box is located in the DAQ Counting Room. Its purpose is to halt the data taking when the system is saturated with event data. When the multievent buffers in the Fr... wikitext text/x-wiki == Overview == The Busy Box is located in the DAQ Counting Room. Its purpose is to halt the data taking when the system is saturated with event data. When the multievent buffers in the Front End Electronics run full, the Busy Box asserts a busy-signal to the Local Trigger Unit which halts the issuing of new triggers. The the busy-signal will be deasserted once there are available buffers. To calculate the number of used mulitevent buffers the Busy Box listens to the trigger system to see which events have been triggered, and then poll all the DRORCs to see which events have been transfered to DAQ. === Download Section === 47bfae1aae25b3d7814ed855ff6c70375d6b11a4 0 4 7 2009-02-18T09:53:22Z Nfyku 4 New page: === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RC... wikitext text/x-wiki === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.2.bin armboot_v2.2.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3.bin armboot_v2.3.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://www.ift.uib.no/~alme/wiki/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://www.ift.uib.no/~alme/wiki/xilinx_hwicap.o xilinx_hwicap.o] | [http://www.ift.uib.no/~alme/wiki/loop.o loop.o] | [http://www.ift.uib.no/~alme/wiki/readme.txt readme.txt] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.4.bin armboot_v2.4.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.5.bin armboot_v2.5.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.6.bin armboot_v2.6.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.61.bin armboot_v2.61.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.62.bin armboot_v2.62.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://www.ift.uib.no/~alme/wiki/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://www.ift.uib.no/~alme/wiki/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://www.ift.uib.no/~alme/wiki/vreg.jed vreg.jed]<br> ispVM System Project File: [http://www.ift.uib.no/~alme/wiki/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </li> </ul> <br><br> === Download Section === [http://www.ift.uib.no/~alme/wiki/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://www.ift.uib.no/~alme/wiki/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://www.ift.uib.no/~alme/wiki/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i><br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> d9ce1687974ecfe5213e84df18d9303419b3b029 8 2009-02-18T09:55:45Z Nfyku 4 wikitext text/x-wiki == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.2.bin armboot_v2.2.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3.bin armboot_v2.3.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://www.ift.uib.no/~alme/wiki/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://www.ift.uib.no/~alme/wiki/xilinx_hwicap.o xilinx_hwicap.o] | [http://www.ift.uib.no/~alme/wiki/loop.o loop.o] | [http://www.ift.uib.no/~alme/wiki/readme.txt readme.txt] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.4.bin armboot_v2.4.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.5.bin armboot_v2.5.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.6.bin armboot_v2.6.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.61.bin armboot_v2.61.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.62.bin armboot_v2.62.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://www.ift.uib.no/~alme/wiki/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> 7fe67753b7a3fc104d1af4b86ef720120bfee26d 9 2009-02-18T09:56:58Z Nfyku 4 wikitext text/x-wiki == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.2.bin armboot_v2.2.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3.bin armboot_v2.3.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://www.ift.uib.no/~alme/wiki/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://www.ift.uib.no/~alme/wiki/xilinx_hwicap.o xilinx_hwicap.o] | [http://www.ift.uib.no/~alme/wiki/loop.o loop.o] | [http://www.ift.uib.no/~alme/wiki/readme.txt readme.txt] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.4.bin armboot_v2.4.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.5.bin armboot_v2.5.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.6.bin armboot_v2.6.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.61.bin armboot_v2.61.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.62.bin armboot_v2.62.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://www.ift.uib.no/~alme/wiki/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://www.ift.uib.no/~alme/wiki/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://www.ift.uib.no/~alme/wiki/vreg.jed vreg.jed]<br> ispVM System Project File: [http://www.ift.uib.no/~alme/wiki/vreg.xcf vreg.xcf]<br><br> 43c2a2ee4f5d27588bce6d5d2fa7e3f18ecd0280 10 2009-02-18T09:59:22Z Nfyku 4 wikitext text/x-wiki == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.2.bin armboot_v2.2.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3.bin armboot_v2.3.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://www.ift.uib.no/~alme/wiki/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://www.ift.uib.no/~alme/wiki/xilinx_hwicap.o xilinx_hwicap.o] | [http://www.ift.uib.no/~alme/wiki/loop.o loop.o] | [http://www.ift.uib.no/~alme/wiki/readme.txt readme.txt] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.4.bin armboot_v2.4.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.5.bin armboot_v2.5.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.6.bin armboot_v2.6.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.61.bin armboot_v2.61.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.62.bin armboot_v2.62.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://www.ift.uib.no/~alme/wiki/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://www.ift.uib.no/~alme/wiki/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://www.ift.uib.no/~alme/wiki/vreg.jed vreg.jed]<br> ispVM System Project File: [http://www.ift.uib.no/~alme/wiki/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </li> </ul> <br><br> === Download Section === [http://www.ift.uib.no/~alme/wiki/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://www.ift.uib.no/~alme/wiki/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://www.ift.uib.no/~alme/wiki/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i><br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://www.ift.uib.no/~alme/wiki/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://www.ift.uib.no/~alme/wiki/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://www.ift.uib.no/~alme/wiki/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://www.ift.uib.no/~alme/wiki/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://www.ift.uib.no/~alme/wiki/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://www.ift.uib.no/~alme/wiki/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] <br><br> == Radiation related issues == TBA a6ee7f457e89d235ef345db83a23b9ae66a7892a 11 2009-02-18T09:59:56Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] <br><br> == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.2.bin armboot_v2.2.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3.bin armboot_v2.3.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://www.ift.uib.no/~alme/wiki/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://www.ift.uib.no/~alme/wiki/xilinx_hwicap.o xilinx_hwicap.o] | [http://www.ift.uib.no/~alme/wiki/loop.o loop.o] | [http://www.ift.uib.no/~alme/wiki/readme.txt readme.txt] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.4.bin armboot_v2.4.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.5.bin armboot_v2.5.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.6.bin armboot_v2.6.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.61.bin armboot_v2.61.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.62.bin armboot_v2.62.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://www.ift.uib.no/~alme/wiki/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://www.ift.uib.no/~alme/wiki/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://www.ift.uib.no/~alme/wiki/vreg.jed vreg.jed]<br> ispVM System Project File: [http://www.ift.uib.no/~alme/wiki/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </li> </ul> <br><br> === Download Section === [http://www.ift.uib.no/~alme/wiki/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://www.ift.uib.no/~alme/wiki/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://www.ift.uib.no/~alme/wiki/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i><br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://www.ift.uib.no/~alme/wiki/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://www.ift.uib.no/~alme/wiki/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://www.ift.uib.no/~alme/wiki/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://www.ift.uib.no/~alme/wiki/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://www.ift.uib.no/~alme/wiki/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://www.ift.uib.no/~alme/wiki/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] <br><br> == Radiation related issues == TBA 2ea3a220c061e072757e18aa2f5cb9229558bdc3 0 5 13 2009-02-18T10:06:05Z Nfyku 4 New page: [[Category:DCS]] == Purpose == This page acts as a knowledge base for parts of the ALICE Detector Control System (DCS), namely the control of the Front-end electronics of several sub-dete... wikitext text/x-wiki [[Category:DCS]] == Purpose == This page acts as a knowledge base for parts of the ALICE Detector Control System (DCS), namely the control of the Front-end electronics of several sub-detectors of ALICE. Since we are mainly involved in the TPC Front-end Electronics, this site may be a bit biased. But it may evolve to a more comprehensive data base for other detectors as well. __TOC__ == Overview == The Detector Control System (DCS) is one of the major modules of the ALICE detector. In general, it covers the tasks of controlling the cooling system, the ventilation system, the magnetic fields and other supports as well as the configuration and monitoring of the Front-end electronics. This page will only cover topics related to the latter. More information on the DCS in general can be found at the [http://alicedcs.web.cern.ch/AliceDCS DCS website]. So far, the following sub-detectors use a number of common components which have been developed in a joint effort: * [http://aliceinfo.cern.ch/Collaboration/ALICE_Project/TPC/index.html Time Projection Chamber (TPC)] * [http://www-alice.gsi.de/trd/index.html Transition Radiation Detector (TRD)] * Photon Spectrometer (PHOS) * Forward Multiplicity Detector (FMD) * EMCAL (new) They all use the DCS board as controlling node on the hardware level. Thus, the communication software can be (almost) identically. The DCS board is a custom-made board with an Altera FPGA that includes an ARM core, which provides the opportunity to run a light-weight Linux system on the card. The board interfaces to the front-end electronics via a dedicated hardware interface and connects to the higher DCS-layers via the DIM communication framework over Ethernet. Furthermore, all detectors but the TRD use a similar hardware setup in the front-end electronics: the Front-End Cards are based on the ALTRO chip and served by Readout Control Units (RCUs). Below is a figure exemplarily for the TPC. [[Image:TPC-FEE blockdia.png|frame|none|Blockdiagram of the TPC Front-end electronics]] === Software Architecture === The DCS consist of three main functional layers. From top to bottom this is: * The Supervisory Layer. The Supervisory Layer provides a user interfaces to the operator. It also communicates with external systems for the LHC * The Control Layer. The Supervisory Layer communicates with the Control Layer mainly through a LAN network. This layer consists of PCs, PLCs (Programmable Logic Cells) and PLC like devices. The Control Layer collects and processes information from the Field Level, as well as sending commands and information from the Supervisory Layer to the Field Layer. It also connects to the Configuration Database. * The Field Layer. The Field Layer consists of all field-devices, sensors, actuators and so on. The DCS board and the readout electronics is located in this layer. For the ALICE experiment, PVSS II has been chosen as SCADA (Supervisory Control And Data Acquisition) system (i.e. the Supervisory Layer). The PVSS connects to the InterComLayer, a specific communication software acting as the Control Layer and connecting the hardware devices in the Field Layer to the controlling system in the Supervisory Layer. The system uses the communication framework [http://www.cern.ch/dim DIM (Distributed Information Management)]. To interfaces are defined for the DCS which abstract the underlaying hardware: * PVSS and InterComLayer communicate through a specific interface, the Front-End-Device (FED), which is common among different sub-detectors within the ALICE experiment. The InterComLayer implements a server which the PVSS can subscribe to as a client. * Each hardware device implements a Front-End-Electronics-Server (FeeServer), which the InterComLayer subscribes to as a client. The InterComLayer connects to several FeeServers and pools data before distributing it to the SCADA system. Vice versa the InterComLayer distributes configuration data to the FeeServers. In addition it implements an interface to the Configuration Database containing all specific configuration data for the hardware devices. [[Image:FeeComChain.PNG|frame|none|Schematic overview of the DCS communication software]] === Hardware Components === * DCS board * Readout-Control-Unit * Frontend Cards * TRD Readout board == The communication software == [[Image:FEE-chain.png|frame|none|DCS data flow for the TPC Front-End-Electronics.]] === Communication Protocol === Communication between all layers is based on the DIM protocol. DIM is an open source communication framework developed at CERN. It provides a network-transparent inter-process communication for distributed and heterogeneous environments. TCP/IP over Ethernet is used as transport layer. A common library for many different operating systems is provided by the framework. DIM implements a client-server relation with two major functionalities. * Services: The DIM server publishes so called services and provides data through a service. Any DIM client can subscribe to services and monitor their data. The DIM clients get notified about current values via a callback from the DIM server. * Commands: A DIM server can accept commands from DIM clients. Server and client have to agree on the format of the command. Here applies the same for the possible data types like for the services. A dedicated DIM name-server takes control over all the running clients, servers and their services available in the system. Each server registers at startup all its services and command channels. For a client the location of a server is transparent. It asks the DIM name-server which server provides a specific service and retrieves the access information. The process then connects directly to the corresponding server. The DIM name-server concept eases a recovery process of the system after update and restart of servers or clients at any time. It enables also fast migration from one machine to another and distributed tasks. Whenever one of the processes (a server or even the name server) in the system crashes or dies all processes connected to it will be notified and will reconnect as soon as it comes back to life. === PVSS === === InterComLayer === The InterComLayer takes the task of the Control Layer. It runs independently from the other system layers on a separate machine outside of the radiation area. It provides three interfaces: * Front-End-Electronics Client (DIM client) to connect to the Field Layer * Front-End-Device Server (DIM server) to connect to the Supervisory Layer * Interface to the Configuration Database, using a database client [[Image:FeeCom-Software.png|frame|none|The InterCom layer in the data flow of the FeeCommunication software.]] The FEE interface consists of a command channel, a corresponding acknowledge channel, a message channel and several service channels. These services are referred to be values of interest like temperature, voltage, currents, etc. of the Front-end electronics. In order to reduce network traffic the FeeServer can apply thresholds for data value changes, so called dead-bands. Changes are only published if a certain dead-band is exceeded, the dead-band can be defined for each service independently in conformity with the different nature of the data. The InterComLayer connects to FeeServers according to the configuration. After the connection is established, the InterComLayer subscribes to the services of the FeeServers and controls their message channels. Filtering of messages according to the log-level is performed on each layer to reduce network traffic. The service channels of the FeeServers are pooled together and re-published to the supervisory level. By this means the source of the services is transparent to the SCADA system on top. The InterComLayer is an abstraction layer, which disconnects Supervisory and Field Layer. In order to transport configuration data to the Front-end electronics, the InterComLayer has an interface to the configuration database. Neither database nor InterComLayer know about the format of the data. The data will be handled as BLOBs (Binary Large OBjects). The database contains entries of configuration packages. For each specific configuration of the Front-end electronics it creates a descriptor which refers to the required configuration packages. The Supervisory Layer sends a request to load a certain configuration to the InterComLayer, which then fetches the corresponding ''BLOB'' from the configuration database and transports it through the command channel to the FeeServers. In addition, the InterComLayer provides functionality for maintenance and control of the FeeServers. Servers can be updated, restarted and their controlling properties can be adjusted to any requirements. For further details go to the [[InterCom Layer]] page. ==== Compiliation and Installation ==== It exists a dedicated description for compiling and installing the [[InterComLayer installation]]. === The Front-End-Electronics-Server === The DCS for the Front-end elctronics is based on so called Front-End-Electronics-Servers (FeeServers), which are running on the DCS board close to the hardware. A FeeServer abstracts the underlying Front-end electronics to a certain degree and covers the following tasks: * Interfacing hardware data sources and publishing data * Receiving of commands and configuration data for controlling the Front-end electronics * Self-tests and Watchdogs (consistency check and setting of parameters) In order to keep development simple and the software re-usable for different hardware setups the FeeServer has been splitted into a device independent core and an interface to the hardware dependent functionality. It exists a dedicated description for compiling and installing the [[FeeServer]], as well as some hints and guidelines for developing an own [[FeeServer#ControlEngine guidelines|ControlEngine]] (CE) for the FeeServer. ==== The FeeServer core ==== The core of the FeeServer is device-independent. It provides general communication functionality, remote control and update of the whole FeeServer application. Some features are related to the configuration of the data publishing. In order to reduce network traffic, variable deadbands have been introduced. Data is only updated if the variation exceeds the deadband. The core can be used for different devices, i.e. different detectors of the ALICE experiment. The device-dependent actions are adapted for each specific device and are executed in separated threads. This makes a controlled execution possible. If execution is stuck, the server core is still running independently. It can kill and clean up the stuck thread and notify the upper layers. ==== The ControlEngine (CE) ==== The ControlEngine implements the device dependent functionality of the FeeServer. The CE provides data access in order to monitor data points and executes received commands specific for the underlying hardware. An abstract interface between FeeServer and CE is defined, the ControlEngine implements interface methods for initializing, cleaning up and command execution. It has contact to the specific bus systems of the hardware devices. The access is ancapsulated in Linux device drivers. This makes the functionality of the CE independent from the hardware/firmware version. One example is the CE for the TPC detector and the RCU. Please check the dedicated site [[RCU ControlEngine]]. === DCS board tools === This sections covers the DCS board software for the TPC-like detectors (so far TPC, PHOS, most likely FMD and EMCAL). Apart from the mentioned FeeServer there are some low level tools and interfaces. In fact, the FeeServer uses them. ...[[DCS board tools| read more]]. == Specifications == === Front-End-Device interface === The FED API is common among all detectors in ALICE. It defines the interface between the FedServer(s) and the PVSS system of one detector. A more detailed description you will find in the document itself. This is the version currently (03.02.2006) also available at the DCS pages: [http://www.ift.uib.no/~kjeks/download/documents/FedServerAPI-v2.0.pdf FED API v2.0 (draft)] === Front-End-Electronics interface === === Control Engine interface === === [[DCS_board_tools#Message_Buffer_access_.28RCU_interface.29 | Message Buffer Interface]] === === [[RCU ControlEngine]] === === Format of TPC configuration data === == [[DCS FAQ]] == == [[DCS Download]] == == [[DCS Tutorial|How to set up a FeeCom chain]]== == [[Setup of low-level DCS for TPC Front-end electronics]]== == [[Setting up a local DCS network]]== == Links == * [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc The ALICE TPC Front End Electronics] * [http://alicedcs.web.cern.ch/AliceDCS/ ALICE Detector Control System group] * [http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/ The DCS board pages] * [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html ARM linux on the DCS board] * [http://www.ztt.fh-worms.de/en/projects/Alice-FEEControl/index.shtml FeeCom Software] * [http://www.cern.ch/dim Distributed Information Management System (DIM)] ---- ---- f2bcee80f6aa270361172a4c4005be8270bbc242 0 6 14 2009-02-18T10:06:39Z Nfyku 4 New page: ==Introduction== This is the documentation of the PVSS monitoring tool for the Front End Electronics (FEE) of the ALICE PHOS detector. The values are read from [[DIM]] and displayed in a G... wikitext text/x-wiki ==Introduction== This is the documentation of the PVSS monitoring tool for the Front End Electronics (FEE) of the ALICE PHOS detector. The values are read from [[DIM]] and displayed in a GUI. ==Feeserver services== *A13V0: Analog 13.0 V voltage. *A13V0C: Current for the analog 13.0 V channel. *A3V3: Analog 3.3 V voltage. *A3V3C: Current for the analog 3.3 V channel. *A6NV0: Analog -6.0 V voltage. *A6N0C: Current for the -6.0 V channel. *A6PV0: Analog 6.0 V voltage. *A6PV0C: Current for the 6.0 V channel. *D3V3: Digital 3.3 V voltage. *D3V3C: Current for the digital 3.3 V channel. *D4V0: Digital 4.0 V voltage. *D4V0C: Current for the digital 4.0 V channel. *TEMP1: Temperature sensor 1. *TEMP2: Temperature sensor 2. *TEMP3: Temperature sensor 3. ==Datapoint types (DPTs)== Datapoint types used in the program: *AliPHS_FEC: Represents one Front End Card (FEC). There is one datapoint element (DPE, variable) for each service published from the FEE-server. *AliPHS_RCU: Represents one RCU. Values from [[DIM]] are read in to feeserver_Services DPE-branch and then mapped to the correct FEC. The feeserver_stat branch containes the maximum value of each service for all FECs in the RCU. *AliPHS_Status: Represents one module. The DPEs contains the maximum value of each service for all FECs in the module. *AliPHS_ICOM: Represents the InterComLayer. The DPEs contains messages from the InterComLayer and configuration commands to be sent. ==Setup script (phsFed_setup.ctl)== The setup script creates all datapoints and sets up the DIM configuration. This script should only be ran once and by experts. ==Mapping script (phsFed_map.ctl)== The mapping scripts maps the DIM services from the AliPHS_RCU feerserver_Services branch to the right AliPHS_FEC datapoint. ==Get max script (phsFed_get_max.ctl== Finds the maximum value for each service for all FECs in one RCU. The values are written to the AliPHS_RCU feeserver_stat branch. ==Check all states for one RCU script (AliPhs_FECs_Up.ctl)== Checks all states of one RCU and writes to the AliPHS_RCU feeserver_stat.AllFecOk datapoint element. ==Get maximum of maximums script(phs_fed_get_total_max.ctl))== Finds the maximum of the maximum values for each RCU for one module and writes it to the AliPHS_Status DPEs. ==Check all states for one module script (phsFed_check_all_states.ctl)== Checks states for all FEC for one module and writes it to the AliPHS_Status ALL_FecOk DPE. ==AliPhsMonitoringDisplay (Main panel)== [[Image:AliPhsMonitoringDisplay.png|830px]] This is the main monitoring panel. It consists of one tab for each service group and one for the state. The color represents the maximum value of the service for the RCU. If you click on the square representing an RCU a new panel with all values for all FECs on the RCU will pop up. Each tab contains a subpanel (named AliPhsA13V0Max.pnl, etc). Each RCU-square is made from a reference panel (named refAliPhsA13V0.pnl, etc) The reference panel change color when the maximum value for the corresponding RCU changes. ==FEC table== [[Image:AliPhsRCUTable2.png|830px]] ==Control panel== [[Image:AliPhsControl.png|400px]] 84158c7866fc8cbba9fdbf8a8cdc08d357bf7ea1 0 7 15 2009-02-18T10:07:08Z Nfyku 4 New page: '''Frame Generation Tool'''<br><br> '''''General'''''<br> This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To g... wikitext text/x-wiki '''Frame Generation Tool'''<br><br> '''''General'''''<br> This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br><br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames.<br> <br> '''''Creating frames'''''<br> Generating the frames is done in these steps:<br> 1. Load the bit-file for the FPGA<br> 2. Type the name of the device as you can see above in “DeviceName”<br> 3. Load the XML configuration file<br> 4. Type the directory where the frames are saved to<br> 5. Press the “Split” button<br> If the frames were generated successfully or an error occurred you will see a message.<br> <br> '''''Creating binary command blocks'''''<br> This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> '''''Uploading to a dedicated location'''''<br> To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> '''NOTE''': the remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. 31d9bf4d154cb98ed61b0f87ef3389841b32634c 0 8 16 2009-02-18T10:07:35Z Nfyku 4 New page: [[Category:HLT]] == HLT == Here you will find informations around the developing of the HLT (High Level Trigger) for [http://aliceinfo.cern.ch/index.html ALICE], especially for the [http:... wikitext text/x-wiki [[Category:HLT]] == HLT == Here you will find informations around the developing of the HLT (High Level Trigger) for [http://aliceinfo.cern.ch/index.html ALICE], especially for the [http://aliceinfo.cern.ch/Collaboration/ALICE_Project/TPC/index.html TPC]. Another important source of knowledge for this topic are the [http://www.kip.uni-heidelberg.de/wiki/HLT/index.php/Main_Page HLT pages] the corresponding Wiki of the [http://www.kip.uni-heidelberg.de Kirchhoff Institute (KIP)] of the [http://www.uni-heidelberg.de University of Heidelberg]. ---- Wanted pages for here are: - [[HLT Overview]] - [[HLT Cluster]] - [[Publish/Subscriber]] Framework (developed by Timm M. Steinbeck) - [[Online reconstruction]] - [[HLT - AliEn interface]] 9324e8d018a2da050e86fd1638ae9d5111bfc1c3 0 9 17 2009-02-18T10:08:30Z Nfyku 4 New page: [[Category:GRID]] == Purpose == The LHC experiments will produce unprecedented amounts of data, reaching several PB/year for a standard ALICE data taking year. Handling such amounts of dat... wikitext text/x-wiki [[Category:GRID]] == Purpose == The LHC experiments will produce unprecedented amounts of data, reaching several PB/year for a standard ALICE data taking year. Handling such amounts of data clearly calls for automated procedures for analysis and data management. Grid techniques will be used to handle the worldwide computing task necessary to extract the ALICE physics results. The general idea of a computing grid is to make world wide computing resources seamlessly available in analogy to information diffusion by World Wide Web. Several Grid prototypes are being developed, but there are still a long range of challenges to provide a full fledged Grid solution. __TOC__ == Grid systems == Several Grid systems are being developed, among them the [http://public.eu-egee.org/ gLite/EGEE] system being developed by a European project, and the [http://www.opensciencegrid.org Open Science Grid] with American roots. The ARC middleware developed by the [http://www.nordugrid.org NorduGrid] project is being actively used in the Nordic countries. The ALICE collaboration has developed the Grid prototype [http://alien.cern.ch AliEn (Alice Environment)]. As other middleware evolves, AliEn will be changed into a common high level interface for the ALICE collaboration. == Grid dictionary == Grid is a rapidly evolving technology. With its roots in Computer Science, it is hardly surprisning to find that it contains a lot of names and acronyms. The following is a non-exhaustive list of relevant terms for the ALICE grid activity: ; AliEn - Alice Environment : Grid prototype developed by the ALICE collaboration. Originally used as a "standalone" Grid prototype, AliEn will be further developed with interfaces to major Grid middleware systems, and will be used as a common platform for all Grid based analysis in ALICE. ; LCG - LHC Computing Grid : A common project set up to coordinate computing needs for all LHC experiments. LCG is also the name of a Grid middleware package. This will be merged into the software to be developed by the common European project EGEE. The LCG project will be maintained with the perspective of organising LHC computing (which is far more than middleware development). ; EGEE - Enabling Grids for E-Science in Europe : EU-funded project to develop a general Grid middleware for scientific needs. The EGEE project has strong roots in the original LCG project. The current version of the EGEE middleware is called gLite. ; gLite : Common European middleware developed by the EGEE project (see above). This middleware will be used by most of the European Tier-1 centres (The Nordic centre being an exception). ; OSG - Open Science Grid : US computing infrastructure including Grid middleware. To be used by US and other computing centres also for LHC computing. ; NorduGrid : A Nordic project that has developed a Grid protoype now distributed as ARC. This middleware has widespread use in Scandinavia and Northern Europe, and has been widely used in ATLAS data challenges. ; ARC - Advanced Resource Connector : Middleware developed by the NorduGrid project. This middleware will be used by the Nordic Tier-1 centre. Interfacing between AliEn and ARC will be developed. ; Tier-x : The computer centres that will take part in LHC data processing have been organised in a hierarchical structure, so that Tier-0 is at CERN, where all data will originally be recorded. There will be a limited number of Tier-1 centres, which will be manned/serviced 24/7, and which will provide permanent storage facilities along with computing resources. Tier-2 centres will connect to CERN through a Tier-1 centre, and will basically provide computing resources. ; Nordic Tier-1 centre : The Nordic countries have agreed to provide distributed Tier-1 centre for LHC processing. This centre will appear as one entity towards the central facility at CERN, but will be physically distributed amongcomputing centres in the Nordic countries. All the participating centres will fulfill the service level requirements for a Tier-1 centre. The Nordic Tier-1 centre will use ARC as its middleware for the internal distribution of jobs and resources. ; NDGF - Nordic Data Grid Facility : The organisation that has been set up to manage the Nordic Tier-1 centre. No machines are owned or runned by NDGF, the organisation provides resources and some manpower to existing computing centres. ; Condor : A system to handle jobs in a heterogenous distributed computer environment. ARC uses Condor to handle jobs inside each participating computer cluster. ; VO - Virtual Organisation : Logical Grid subdivision grouping Grid users belonging to the same project, who should have access to the same resources. As an example ALICE will be a VO. ; VO Box : In a full-fledged Grid all necessary computing resources should be handled through Grid mechanisms, and the user should not care where a given job is actually handled. As Grid middleware is still a project under development, and as LHC needs data processing at startup in 2007, it has been agreed upon an "interim" solution allowing each VO to have access to dedicated computing resources at each participating centre, where specific software can be installed. Experiment responsibles may have root access at the VO Box, but not at the general computing resources. ; CE - Computing element : The part of the Grid middleware that do job management, and handles CPU resources. The AliEn installation at the hansa cluster in Bergen will use Condor as its Computing Element. ; SE - Storage element : The part of the Grid middleware that handle files residing locally. In Tier-1 centres, which will provide permanent storage for Grid-wide access, this will normally be some storage management system including a tape robot and staging space on disk. At the hansa cluster a 250 GB disk is set aside to operate as a Grid SE for AliEn. ; FTD - File Transfer Daemon : The part of the Grid middleware that handle transport of files between sites. This should happen transparently, so that the user in principle should not need to be aware of where the file is actually located. Authentication issues are handled through Grid certificates, which are somewhat parallell to SSH keys used for traditional remote computing. == AliEn in Bergen == System resources for ALICE Grid production will be operated by [http://www.parallab.uib.no Parallab] connected to the [http://www.ndgf.org Nordic Data Grid Facility]. The NDGF will run ARC as its basic middleware. The necessary software to interface ARC and AliEn is currently being developed. For development and prototyping purposes, Grid software is also installed in the local cluster at the Department of Physics and Technology, called hansa. The following information provides more details on the Grid/AliEn installation on the hansa cluster. == Needed tools == The AliEn software needs a batch system underneath to run and distribute jobs. AliEn supports many different batch systems, like BQS, CONDOR, DQS, Globus, LSF and PBS. For hansa we are using [http://www.cs.wisc.edu/condor/ Condor], in order to be able to use its [http://www.cs.wisc.edu/condor/manual/v6.6/5_2Connecting_Condor.html Flocking] feature. On top of it [http://alien.cern.ch ''AliEn''] will be installed to participate in the AliEn grid. == Installing Condor == [http://www.cs.wisc.edu/condor Condor] is developed by the [http://www.cs.wisc.edu/ University of Wisconsins Madison]. A detailed description of the [[Condor Installation on hansa]] can be found here. == Installing AliEn == [http://alien.cern.ch AliEn] is developed at [http://www.cern.ch CERN] as GRID middleware for [http://aliceinfo.cern.ch/ ALICE]. A detailed description of the [[AliEn installation on hansa00]] can be found here ''(preliminary)''. General description for [[General AliEn Installation|installing AliEn]] is here.. == GRID Meeting Minutes == Here are the [[GRID Meeting Minutes|minutes]] from our (weekly) GRID meeting at Høygskolen, starting with November the 27th 2006. 5bc6d7e11a527f8a6b04c5a25b8afb44d51d3182 6 10 22 2009-02-18T10:52:44Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 11 23 2009-02-18T10:54:43Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 12 24 2009-02-18T11:07:28Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 13 25 2009-02-18T11:34:52Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 14 26 2009-02-18T11:35:33Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 15 27 2009-02-18T11:36:31Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 16 28 2009-02-18T11:37:19Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 17 29 2009-02-18T11:37:53Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 18 30 2009-02-18T11:38:21Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 19 31 2009-02-18T11:39:29Z Nfyku 4 New page: == Overview == As described in [[Electronics for the Time Projection Chamber (TPC)]] the RCU has an Active Partial Reconfiguration (APR) network to reconfigure the Xilinx SRAM based FPGA i... wikitext text/x-wiki == Overview == As described in [[Electronics for the Time Projection Chamber (TPC)]] the RCU has an Active Partial Reconfiguration (APR) network to reconfigure the Xilinx SRAM based FPGA in case there appear errors due to the radiation environment. This reconfiguration network includes some Flash memory and the Actel Flash based FPGA. The main task of the Actel software device is to monitor and control the operation of the Actel FPGA. For this reason it offers different services, as monitoring different registers that give information about the state of the hardware, to control the main operation modes of the Actel FPGA and to program the Flash memory for the Active Partial Reconfiguration solution to work. The Actel FPGA features three ways to configure the Xilinx Virtex-II Pro FPGA: *Initial Configuration : Configures the Xilinx Virtex-II Pro once during startup or on command from the DCS board. *Scrubbing : Continously overwrites the configuration memory of the Xilinx Virtex-II Pro, wether an error occured or not. *Frame by Frame readback and error correction : The Actel reads back the single configuration frame of the Xilinx Virtex and compares them to the configuration data stored in the Flash memory on the RCU. For this Active Partial Reconfiguration solution to work, the Flash memory has to be programmed with the correct firmware for the Xilinx FPGA. There are two ways on how to program the Flash memory: *The rcuflashprog command line tool *the here described Actel software device Information about the Actel FPGA and the rcuflashprog tool can be found at: [[Electronics for the Time Projection Chamber (TPC)#RCU Auxilliary FPGA Firmware for TPC and PHOS]] 7b3c5e188b85a0149e3ac7f83d04960a5e025241 6 20 32 2009-02-18T11:41:25Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 21 33 2009-02-18T12:10:45Z Dfe002 7 New page: == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical application... wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, Kjetil * Engineers: Dominik, Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. e894e51a0ef67caf5cd7161861adec3913dfc6e6 0 22 34 2009-02-18T13:30:38Z Dfe002 7 New page: == Characterisation Cell == == Characterisation setup and results == wikitext text/x-wiki == Characterisation Cell == == Characterisation setup and results == 9112aac100024e7144dacf3a3cce072ba445e786 41 2009-02-18T13:39:29Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. PETscan.jpg Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET senter at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == Characterisation Cell == == Characterisation setup and results == 2d316f1a4a014a15be9379bd3b4b6656977443d1 43 2009-02-18T13:40:40Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETscan.jpg|frame|none|]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET senter at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == Characterisation Cell == == Characterisation setup and results == cbe4bd122dee9de7f5077116028c65ed5eb9fce2 48 2009-02-18T13:44:28Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET senter at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == Characterisation Cell == == Characterisation setup and results == 36d2939a5c7bcb721845f9cf7676ed422aac4239 0 23 35 2009-02-18T13:30:55Z Dfe002 7 New page: == 3D setup == wikitext text/x-wiki == 3D setup == 72bd4c5cde540f6e3c2dd38834b709ca885e59a4 36 2009-02-18T13:32:27Z Dfe002 7 wikitext text/x-wiki = Introduction to 3D detectors = 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: More information * Testbeam talk by Erlend and Ole * 3D workshop in Barcelona * 3D-state of the art * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328) Our Activities * TestBeam Analysis * 3DSensor Characteristics * 3DMeasurement System Who are we? * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... 25902ddbb4ac1eb47de2bcd44b3e7071c52f1458 37 2009-02-18T13:33:17Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: == More information == * Testbeam talk by Erlend and Ole * 3D workshop in Barcelona * 3D-state of the art * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328) == Our Activities == * TestBeam Analysis * 3DSensor Characteristics * 3DMeasurement System == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... ee99b667408c26e151ef0f69a270c5df4f4b9b56 38 2009-02-18T13:34:39Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: == More information == * Testbeam talk by Erlend and Ole * 3D workshop in Barcelona * 3D-state of the art * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328) == Our Activities == * TestBeam Analysis * 3DSensor Characteristics * 3DMeasurement System == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... c8ed61cc42f19cb822a4a0b546b02d9e4e305388 0 24 39 2009-02-18T13:35:29Z Dfe002 7 New page: == General information == Information about ILC, CALICE and calorimeter detectors can be found here: * http://ilcagenda.cern.ch/conferenceOtherViews.py?confId=1049&view=cdsagenda&showDat... wikitext text/x-wiki == General information == Information about ILC, CALICE and calorimeter detectors can be found here: * http://ilcagenda.cern.ch/conferenceOtherViews.py?confId=1049&view=cdsagenda&showDate=all&showSession=all&detailLevel=contribution == Our projects == * About Calorimeter tesbeam? * Calorimeter Measurement System? be5a658a8ceb086348e192d7b3e0d06238b84e76 40 2009-02-18T13:35:43Z Dfe002 7 wikitext text/x-wiki == General information == Information about ILC, CALICE and calorimeter detectors can be found here: * http://ilcagenda.cern.ch/conferenceOtherViews.py?confId=1049&view=cdsagenda&showDate=all&showSession=all&detailLevel=contribution == Our projects == * About Calorimeter testbeam? * Calorimeter Measurement System? 25c0be5a04776dae31fb369747873a04cb73cf11 0 25 42 2009-02-18T13:39:51Z Nfyku 4 New page: Mikroelektronikk Dokumentasjon for Mentor-programvaren finnes i katalogen /prog/mentor/mgc/ic.2005.1/shared/pdfdocs/ eller /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ - [IC studio ] Vei... wikitext text/x-wiki Mikroelektronikk Dokumentasjon for Mentor-programvaren finnes i katalogen /prog/mentor/mgc/ic.2005.1/shared/pdfdocs/ eller /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ - [IC studio ] Veiledning til IC-design ved hjelp av IC studio - [IC Station] Tegne utlegg for integrerte kretser - [Expedition PCB] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB - [Modelsim] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim - [PCI-eksperiment] Øving med HLT-RORC-prototypekort - [Cadence Virtuoso] - [Xilinx] Øving i bruk av Xilinx Project Studio - [FLTK GUI] Graphical User Interface using FLTK - [Tutorials] Tutorials from the web - [ADS] Getting started with Agilent Advanced Design System 904bf4d5c10c8c257c9ac2b01efe2dd0084f28f0 44 2009-02-18T13:40:57Z Nfyku 4 wikitext text/x-wiki Mikroelektronikk Dokumentasjon for Mentor-programvaren finnes i katalogen /prog/mentor/mgc/ic.2005.1/shared/pdfdocs/ eller /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ - [[IC studio]] Veiledning til IC-design ved hjelp av IC studio - [[IC Station]] Tegne utlegg for integrerte kretser - [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB - [[Modelsim]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim - [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort - [[Cadence Virtuoso]] - [[Xilinx]] Øving i bruk av Xilinx Project Studio - [[FLTK GUI]] Graphical User Interface using FLTK - [[Tutorials]] Tutorials from the web - [[ADS]] Getting started with Agilent Advanced Design System d3eacfc91ce48d5541950ede849ad9167df1af01 46 2009-02-18T13:41:55Z Nfyku 4 wikitext text/x-wiki == Headline text == Mikroelektronikk Dokumentasjon for Mentor-programvaren finnes i katalogen /prog/mentor/mgc/ic.2005.1/shared/pdfdocs/ eller /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System 99b83a499e2009cb8dd49049666b65a56753008d 47 2009-02-18T13:42:28Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor-programvaren finnes i katalogen /prog/mentor/mgc/ic.2005.1/shared/pdfdocs/ eller /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System 9c05f5f5c45bec53806c7e3a0e3d5ecbd0d7c1a2 6 26 45 2009-02-18T13:41:01Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 27 49 2009-02-18T13:45:21Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 28 50 2009-02-18T13:45:42Z Nfyku 4 New page: == Kom igang med IC studio == En veiledning til design og utlegg "Kjetil Ullaland", mailto:Kjetil_punktum_Ullaland@ift.uib.no, *Universitetet i Bergen, Institutt for fysikk og teknologi,... wikitext text/x-wiki == Kom igang med IC studio == En veiledning til design og utlegg "Kjetil Ullaland", mailto:Kjetil_punktum_Ullaland@ift.uib.no, *Universitetet i Bergen, Institutt for fysikk og teknologi,* *Sist oppdatert 18. februar 2009 av Kjetil* Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> =Starte opp IC studio= Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. =Dokumentasjon= Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> =Åpne et nytt skjema= Høyre-klikk Library-vinduet. Velg New View og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "View Type" Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. <img src="uploads/IC_studio_new_view.png" /> velg show palette fra ikonlisten til høyre. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. =Design Viewpoint= Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. =Simulering= Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). =Prober og plot= Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. =Tips= For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. =Bruk av IC station= Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation aff0101edce228e6233a1014344876bad2abadd7 6 29 51 2009-02-18T13:45:52Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 28 52 2009-02-18T13:47:55Z Nfyku 4 wikitext text/x-wiki == Kom igang med IC studio == =En veiledning til design og utlegg= Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> =Starte opp IC studio= Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. =Dokumentasjon= Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> =Åpne et nytt skjema= Høyre-klikk Library-vinduet. Velg New View og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "View Type" Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. <img src="uploads/IC_studio_new_view.png" /> velg show palette fra ikonlisten til høyre. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. =Design Viewpoint= Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. =Simulering= Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). =Prober og plot= Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. =Tips= For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. =Bruk av IC station= Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 48a33d99a3c8f3e33f42bc2d8131b2b43b3f8547 53 2009-02-18T13:48:48Z Nfyku 4 wikitext text/x-wiki == Kom igang med IC studio == ===En veiledning til design og utlegg=== Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> =Starte opp IC studio= Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ===Dokumentasjon=== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ===Åpne et nytt skjema=== Høyre-klikk Library-vinduet. Velg New View og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "View Type" Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. <img src="uploads/IC_studio_new_view.png" /> velg show palette fra ikonlisten til høyre. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ===Design Viewpoint=== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ===Simulering=== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). =Prober og plot= Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ===Tips=== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ===Bruk av IC station=== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation ad0c762b53479b84593c1143a8ad30c4e3d7d537 55 2009-02-18T13:52:00Z Nfyku 4 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg New View og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "View Type" Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. <img src="uploads/IC_studio_new_view.png" /> velg show palette fra ikonlisten til høyre. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 0e314f507c88e6bf1310e31754d651b7cb6759ee 78 2009-02-19T08:44:00Z Nfyku 4 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg New View og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "View Type" Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg show palette fra ikonlisten til høyre. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 94f3db5a7de3de5eb67c6a18a5d37ce2d1da47b9 0 23 54 2009-02-18T13:51:34Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * Testbeam talk by Erlend and Ole * 3D workshop in Barcelona * 3D-state of the art * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328) == Our Activities == * TestBeam Analysis * 3DSensor Characteristics * 3DMeasurement System == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... c19b2ec01f0bd237d51832c1b382eceffb97de1c 56 2009-02-18T14:07:38Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] == Our Activities == * TestBeam Analysis * 3DSensor Characteristics * 3DMeasurement System == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... 5d21990cf7a3659aecf0d8326387b8a147d7e418 0 1 57 2009-02-18T14:48:40Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] Det er meningen at disse sidene skal være lesbare for hele verden. Regner med at det blir fikset snart. == Getting started == Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 46f70a3c89306f92aa1d3131f7a97ab090026a60 4 30 58 2009-02-18T16:22:07Z Nfyku 4 New page: http://www.uib.no/ift Institutt for fysikk og teknologi] Forskningen ved Institutt for fysikk og teknologi er organisert innenfor 9 forskergrupper og dekker et bredt spekter av disipliner... wikitext text/x-wiki http://www.uib.no/ift Institutt for fysikk og teknologi] Forskningen ved Institutt for fysikk og teknologi er organisert innenfor 9 forskergrupper og dekker et bredt spekter av disipliner fra grunnleggende og grensesprengende problemstillinger om universets sammensetning til høyteknologiske prosjekter innen elektronikk eller olje- og gassrelaterte områder. 1aaeca71c4a6364c524d9e189251a00310e1546e 59 2009-02-18T16:22:26Z Nfyku 4 wikitext text/x-wiki [http://www.uib.no/ift Institutt for fysikk og teknologi] Forskningen ved Institutt for fysikk og teknologi er organisert innenfor 9 forskergrupper og dekker et bredt spekter av disipliner fra grunnleggende og grensesprengende problemstillinger om universets sammensetning til høyteknologiske prosjekter innen elektronikk eller olje- og gassrelaterte områder. ce63a2230525d08aba0b595b4369b5bfd1b2c4aa 60 2009-02-18T16:22:48Z Nfyku 4 wikitext text/x-wiki ===[http://www.uib.no/ift Institutt for fysikk og teknologi]=== Forskningen ved Institutt for fysikk og teknologi er organisert innenfor 9 forskergrupper og dekker et bredt spekter av disipliner fra grunnleggende og grensesprengende problemstillinger om universets sammensetning til høyteknologiske prosjekter innen elektronikk eller olje- og gassrelaterte områder. 5dc781c0cf0635f3f228fe515609d25ebe42cf27 0 31 61 2009-02-19T07:08:57Z Nfyku 4 New page: ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon... wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. <img src="uploads/drc_chedr.bmp" /> Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... <img src="uploads/drc_options_2.bmp" /> Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. <img src="uploads/drc_fra_meny.bmp" /> ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpent et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). <img src="uploads/lvs_setup_button.bmp" /> Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. <img src="uploads/lvs_2.bmp" /> Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. <img src="uploads/lvs_setup_2.bmp" /> Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. <img src="uploads/extract_mask_lumped_parameters.bmp" /> Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. <img src="uploads/sch_parasitics _included.bmp" /> Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. d9764024c9340db38f9b82abf31dd6be11420ec9 80 2009-02-19T08:48:04Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.bmp]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.bmp] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image::drc_fra_meny.bmp] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpent et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.bmp] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.bmp] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.bmp]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.bmp]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:uploads/sch_parasitics _included.bmp]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. d2d65e2dd39930fb03804986ea2e46a47a0b57fa 81 2009-02-19T08:55:41Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image::drc_fra_meny.png] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpent et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:uploads/sch_parasitics _included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 17efa785643e463e564695351d24c890f323d400 82 2009-02-19T08:56:44Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image::drc_fra_meny.png] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpent et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. bb0851795e8c060c97ae8b0ab3d588e20b262a90 84 2009-02-19T08:58:01Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image::drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpent et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. f0a9a2f9d474747759641dc9e354713a316ddd62 91 2009-02-19T09:00:37Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpent et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 37b13e9e183dbaf5ed93da755e3cc7a3c787034b 93 2009-02-19T09:02:05Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 91b583faa4c163dbc7acfb3985ae45338cd1cbe6 94 2009-02-19T09:02:43Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Innstillinger for prosessen S35: <pre> Cell name: (Navn på cell/utlegg) Attach library: $AMS_DIR/mentor/ic_station/s35/libraries/s35d4.library Process: $AMS_DIR/mentor/ic_station/s35/process/s35d4.process Rules file: $AMS_DIR/mentor/ic_station/s35/rules/s35d4.rules </pre> ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. f35f7b28f5ac13b9a1300d9c46f9cacaba41c984 0 32 62 2009-02-19T07:10:15Z Nfyku 4 New page: ===Kom igang med Expedition PCB=== En veiledning til design og utlegg *Universitetet i Bergen, Institutt for fysikk og teknologi,* *Sist oppdatert oktober 2007 Dette er en kort beskriv... wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg *Universitetet i Bergen, Institutt for fysikk og teknologi,* *Sist oppdatert oktober 2007 Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable <pre> setenv SDD_ROOT /prog/mentor/exp2005 setenv MGC_HOME /prog/mentor/exp2005/2005EXP/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/exp2005/2005EXP/SDD_HOME </pre> ==Starte utleggsprogrammet=== <pre> /prog/mentor/exp2005/2005EXP/SDD_HOME/common/linux/bin/ExpeditionPCB </pre> ==Skjemategning== Må muligens da sette MGC_HOME til /prog/mentor/mgc/2005.1 <pre> /prog/mentor/mgc/2005.1/bin/da_ic </pre> b6b1c255dde5955cadcaa072463de05a47756e2f 63 2009-02-19T07:10:41Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg Universitetet i Bergen, Institutt for fysikk og teknologi, Sist oppdatert oktober 2007 Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable <pre> setenv SDD_ROOT /prog/mentor/exp2005 setenv MGC_HOME /prog/mentor/exp2005/2005EXP/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/exp2005/2005EXP/SDD_HOME </pre> ==Starte utleggsprogrammet== <pre> /prog/mentor/exp2005/2005EXP/SDD_HOME/common/linux/bin/ExpeditionPCB </pre> ==Skjemategning== Må muligens da sette MGC_HOME til /prog/mentor/mgc/2005.1 <pre> /prog/mentor/mgc/2005.1/bin/da_ic </pre> 2212310d36552aacebdcff4910e3e980d4cd868c 64 2009-02-19T07:11:01Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable <pre> setenv SDD_ROOT /prog/mentor/exp2005 setenv MGC_HOME /prog/mentor/exp2005/2005EXP/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/exp2005/2005EXP/SDD_HOME </pre> ==Starte utleggsprogrammet== <pre> /prog/mentor/exp2005/2005EXP/SDD_HOME/common/linux/bin/ExpeditionPCB </pre> ==Skjemategning== Må muligens da sette MGC_HOME til /prog/mentor/mgc/2005.1 <pre> /prog/mentor/mgc/2005.1/bin/da_ic </pre> bd0e5c6be963c677dbc348bb3b5299a32d18d67f 0 33 65 2009-02-19T07:12:43Z Nfyku 4 New page: Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] 02520b3a826446cadb898f5f72bc07059a5f2c49 0 34 66 2009-02-19T07:15:00Z Nfyku 4 New page: ===Konstruksjon og simulering av VHDL-kode med ModelSim=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av... wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med ModelSim=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås. * Eksempel 2: Signaler og variable. Hvert eksempel beskrives med VHDL som vist i kurskompendiet. I tillegg til VHDL-koden i eksempel 1 trengs en ENTITY-del og en ARCHITECTURE-konstruksjon som omslutter selve programlinjene. Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 6.1 i kurskompendiet er vist nederst i dette dokumentet. Mentor Graphics har utviklet programvare (Modelsim) som gjør det mulig å simulere og debugge VHDL-kode. Design architect kan brukes til å skrive og kompilere VHDL-programmene, men det anbefales å bruke en teksteditor i VHDL-modus, f.eks Emacs. Modelsim brukes til simulering. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs (eller en den innebygde teksteditoren i ModelSim). Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive "M-x vhdl-mode" (M står for "Meta" og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ".vhdl" som "etternavn". (F. eks. sr_latch.vhdl) ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter Modelsim, og startes med kommandoen <pre> vsim & </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. Start et nytt prosjekt med <pre> File > New > Project </pre> Velg et fornuftig navn og katalog. Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) "mentor" sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Modelsim== Når koden kompilerer feilfritt kan den simuleres i Modelsim. Dette startes med: <pre> vsim & </pre> Modelsim bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i ModelSim-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen "force" eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempel: Signalflyt i en SR-lås== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i ModelSim, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv "run 100" i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. "force S 0" i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> Eksempel: Signaler og variable. Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> 5986d8106235482257c81d16f994d44eccf5a160 95 2009-02-19T09:05:47Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med ModelSim=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås. * Eksempel 2: Signaler og variable. Hvert eksempel beskrives med VHDL som vist i kurskompendiet. I tillegg til VHDL-koden i eksempel 1 trengs en ENTITY-del og en ARCHITECTURE-konstruksjon som omslutter selve programlinjene. Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 6.1 i kurskompendiet er vist nederst i dette dokumentet. Mentor Graphics har utviklet programvare (Modelsim) som gjør det mulig å simulere og debugge VHDL-kode. Design architect kan brukes til å skrive og kompilere VHDL-programmene, men det anbefales å bruke en teksteditor i VHDL-modus, f.eks Emacs. Modelsim brukes til simulering. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs (eller en den innebygde teksteditoren i ModelSim). Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn". (F. eks. sr_latch.vhdl) ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter Modelsim, og startes med kommandoen <pre> vsim & </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. Start et nytt prosjekt med <pre> File > New > Project </pre> Velg et fornuftig navn og katalog. Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Modelsim== Når koden kompilerer feilfritt kan den simuleres i Modelsim. Dette startes med: <pre> vsim & </pre> Modelsim bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i ModelSim-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempel: Signalflyt i en SR-lås== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i ModelSim, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Eksempel: Signaler og variable== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> af3c123ea22e388d8b9a80d428e6f3bf88309632 96 2009-02-19T09:07:14Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med ModelSim=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås. * Eksempel 2: Signaler og variable. Hvert eksempel beskrives med VHDL som vist i kurskompendiet. I tillegg til VHDL-koden i eksempel 1 trengs en ENTITY-del og en ARCHITECTURE-konstruksjon som omslutter selve programlinjene. Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 6.1 i kurskompendiet er vist nederst i dette dokumentet. Mentor Graphics har utviklet programvare (Modelsim) som gjør det mulig å simulere og debugge VHDL-kode. Design architect kan brukes til å skrive og kompilere VHDL-programmene, men det anbefales å bruke en teksteditor i VHDL-modus, f.eks Emacs. Modelsim brukes til simulering. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs (eller en den innebygde teksteditoren i ModelSim). Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn". (F. eks. sr_latch.vhdl) ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter Modelsim, og startes med kommandoen <pre> vsim & </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. Start et nytt prosjekt med <pre> File > New > Project </pre> Velg et fornuftig navn og katalog. Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Modelsim== Når koden kompilerer feilfritt kan den simuleres i Modelsim. Dette startes med: <pre> vsim & </pre> Modelsim bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i ModelSim-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i ModelSim, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> 6f42909c4fab5e9ef00df3148a1534716ba2799c 97 2009-02-19T09:12:50Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med ModelSim=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: [[Wikipedia:Signalflyt i en SR-lås]] * Eksempel 2: [[Wikipedia:Signaler og variable]] Hvert eksempel beskrives med VHDL som vist i kurskompendiet. I tillegg til VHDL-koden i eksempel 1 trengs en ENTITY-del og en ARCHITECTURE-konstruksjon som omslutter selve programlinjene. Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 6.1 i kurskompendiet er vist nederst i dette dokumentet. Mentor Graphics har utviklet programvare (Modelsim) som gjør det mulig å simulere og debugge VHDL-kode. Design architect kan brukes til å skrive og kompilere VHDL-programmene, men det anbefales å bruke en teksteditor i VHDL-modus, f.eks Emacs. Modelsim brukes til simulering. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs (eller en den innebygde teksteditoren i ModelSim). Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn". (F. eks. sr_latch.vhdl) ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter Modelsim, og startes med kommandoen <pre> vsim & </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. Start et nytt prosjekt med <pre> File > New > Project </pre> Velg et fornuftig navn og katalog. Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Modelsim== Når koden kompilerer feilfritt kan den simuleres i Modelsim. Dette startes med: <pre> vsim & </pre> Modelsim bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i ModelSim-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i ModelSim, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> 8eb50779eb9cf7139de8897d89070d17311dfaac 98 2009-02-19T09:16:30Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med ModelSim=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Hvert eksempel beskrives med VHDL som vist i kurskompendiet. I tillegg til VHDL-koden i eksempel 1 trengs en ENTITY-del og en ARCHITECTURE-konstruksjon som omslutter selve programlinjene. Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 6.1 i kurskompendiet er vist nederst i dette dokumentet. Mentor Graphics har utviklet programvare (Modelsim) som gjør det mulig å simulere og debugge VHDL-kode. Design architect kan brukes til å skrive og kompilere VHDL-programmene, men det anbefales å bruke en teksteditor i VHDL-modus, f.eks Emacs. Modelsim brukes til simulering. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs (eller en den innebygde teksteditoren i ModelSim). Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn". (F. eks. sr_latch.vhdl) ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter Modelsim, og startes med kommandoen <pre> vsim & </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. Start et nytt prosjekt med <pre> File > New > Project </pre> Velg et fornuftig navn og katalog. Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Modelsim== Når koden kompilerer feilfritt kan den simuleres i Modelsim. Dette startes med: <pre> vsim & </pre> Modelsim bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i ModelSim-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i ModelSim, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> d3f088847ad570ef461c5c838f7b294dae8f4157 0 35 67 2009-02-19T07:18:23Z Nfyku 4 New page: ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit n... wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Del.1 - Do-file== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscilliasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Del.2 Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. d7a6939aa505aedc0c9e60d5a7a2dca404eecee2 68 2009-02-19T07:19:35Z Nfyku 4 wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscilliasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. dec0cda453c8cc1b44fb11fcc14fd05800d8f467 0 36 69 2009-02-19T07:21:16Z Nfyku 4 New page: ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og ett... wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisens i Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Nå du får en "ROOTDIR"-error, må du skrife i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/quartus </pre> Modelsim Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte 'prosjektdir til precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== *Kode til alu_example.vhdl:* <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> *Koden til add_sub_alu.vho* <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> *Koden til alu_tb.vhdl* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> 22571af455f2a1ddedb0ab660d10427afd3e6d5b 70 2009-02-19T07:24:19Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisens i Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/quartus </pre> Modelsim Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte 'prosjektdir til precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== =Kode til alu_example.vhdl= <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> =Koden til add_sub_alu.vho= <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> =Koden til alu_tb.vhdl= <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> d474f794e39876563e1e4b2cd8c4b49743e2c250 71 2009-02-19T07:33:54Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <source> mentor precision </source> Pass på at lisens i Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <source> setenv QUARTUS_ROOTDIR /prog/quartus </source> Modelsim Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte 'prosjektdir til precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <source lang=vhdl> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </source> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <source lang=sh> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </source> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <source lang=vhdl> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </source> ===Koden til add_sub_alu.vho=== <source lang=vhdl> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </source> ===Koden til alu_tb.vhdl=== <source lang=vhdl> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </source> 8dda25a205ee4759b5eef9521d16e37844803060 72 2009-02-19T07:46:37Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <source lang="vhdl"> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </source> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <source lang="vhdl"> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </source> ===Koden til add_sub_alu.vho=== <source lang="vhdl"> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </source> ===Koden til alu_tb.vhdl=== <source lang="vhdl"> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </source> f3aa559a204809c98c6d752e0eb62f2bf97ac0cd 73 2009-02-19T07:52:54Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> 84501b369be527e4c5f37097b42dfd8460bf0088 0 37 74 2009-02-19T07:55:50Z Nfyku 4 New page: =Laboratory exercise for building and running the HLT-RORC hardware/software= ==Simulation in ModelSim== 1. Extract "HLT-RORC.ZIP", file:/heim/torheim/arkiv/HLT-RORC.ZIP into your workin... wikitext text/x-wiki =Laboratory exercise for building and running the HLT-RORC hardware/software= ==Simulation in ModelSim== 1. Extract "HLT-RORC.ZIP", file:/heim/torheim/arkiv/HLT-RORC.ZIP into your working directory. 2. Set environment variable PROJECT_PATH equal to /my_working_directory/HLT-RORC/modelsim. 3. Start modelsim, then open project file HLT-prosjektfil.mpf in directory HLT-RORC/modelsim. 4. Map the simulation libraries. You can do this by typing from the command line (in the following order): <PRE> vlib work # Creating the work library vmap altera_pci /pakke/mgc/altera/vhdl/altera_pci vmap lpm /pakke/mgc/altera/vhdl/220model vmap altera_mf /pakke/mgc/altera/vhdl/altera_mf </PRE> If the compiled simulation libraries have become obsolete, you will have to compile the libraries yourself. This can be done by typing (in the following order): <PRE> vcom &#8211;work altera_mf altera_mf_components.vhd vcom &#8211;work altera_mf altera_mf.vhd vcom &#8211;work lpm 220pack.vhd vcom &#8211;work lpm 220model.vhd </PRE> 5. The mstr_tranx.vhd module contains the master transactions controlling the simulation scenario. To run the simulation with interrupt transfers, set the variable int_or_not equal to 1. To run the simulation with DMA transfers only, set the variable to zero. 6.Now you should compile your testbench with the design into your library work. The testbench could then be loaded by typing <i>vsim -t ps work.testbench</i> from the !ModelSim command line (not specifying the resolution in ps will result in a a fatal error). To run the simulation with 32 bit PCI bus, you could simply type <i>force -freeze /testbench/ack64n 1</i> before running simulation. 7. Run the simulation by typing <i>run ![time in ns]</i>. (You can get rid of all the warnings if you choose <i>Simulate -> Simulation Options -> Assertions -> Ignore assertions for warning</i> from the menu line) ==Synthesizing, technology mapping and transferring the design onto the APEX20KE FPGA== 1. Open Precision RTL Synthesis. Choose <i>File -> New Project</i>. Set the working directory to whatever you want to. 2. Add all the required VHDL files to you project. Make sure local_side.vhd is the last added file (The last added file will automatically be set as top of design). 3. Choose Setup Design to set the following options: APEX 20KE as technology, EP20K400EFC672 as device and -2X for the speed grade. The design frequency shold be 40 !MHz. 4. Click Compile, followed by Synthesize. 5. Close Precision RTL Synthesis. Make sure to anser "Yes" when asked about saving the current implementation. 6. A subdirectory called local_side_impl_1 has now been created in your working directory. Copy the content of local_side_impl_1 to /your_working_directory/HLT-RORC/LS/run_1. Answer yes when questioned to overwrite existing data. 7. Open top_module.qpf from Quartus. Convert the project file to the new Quartus file format if asked to do so. 8. If necessary, choose Tools -> !SignalTap Logic Analyzer and update the SignalTap file to the new file format. 9.Choose Assigments -> Settings -> User Library and add the correct library path (your_working_directory\HLT-RORC\pci_compiler-v2.1.1\lib). The newer versions of the pci core cannot be used, since the APEX20KE has been abandoned from further development. 10. Choose <i>Processing -> Start Compilation</i> to compile the design (this will take some time). 11. Choose <i>Tools -> Programmer</i>. Now choose JTAG as MODE. To make your programming file come through the scan chain, you have to add the device EPM7256B. The EPM device has to be the first on the list. 12. From the file menu you can now choose <i>Create/update -> Create JAM, SVF or ISC file</i>. 13. SSH to pc-rcu.fi.uib.no. Enter the directory where the .jam file has been saved (should be /your_working_directory/HLT-RORC/Quartus) 14. type <i>jamplayer -p378 -aCONFIGURE top_module.jam</i>. In case you receive the following error message: "Error: can't open file "/heim/torheim/rorctest/HLT-RORC/Quartus/top_module.jam", ensure that you have set the correct user privileges for HLT-RORC directory including its files and folders. You can do this by typing chmod -R 666 HLT-RORC. 15. Reboot your system. The HLT-RORC should now be ready and running. On pc-rcu.fi.uib.no, BAR0 will probably be mapped to FB400000. This can be checked by typing <i>/sbin/lspci -v</i> from the command line. ==Verifying the implementation with the Vanguard Logic Analyzer== 1. Start the Analyzer (BusView.exe) 2. Choose <i>File -> New -> Analyzer Setup</i> 3. Add this event: PCI0 in transfer mode with address FD0xxxxx. 4. Add this trigger: <PRE> Samling in TRANSFER mode Store (ALL) If (PCI0) then Trigger at 50% of trace Endif </PRE> 5. Cut and paste this text into an empty text file and save the file as testbench.scr: <PRE> f FB400000 FB400000 FD000000 f FB400004 FB400004 00000400 f FB400008 FB400008 FD000000 f FB40002C FB40002C FD000000 f FB400030 FB400030 FD000000 f FB400018 FB400018 00000011 f FB400020 FB400020 00000019 f FB400024 FB400024 00000001 f FB400024 FB400024 00000000 f FB400028 FB400028 AFFED00F </PRE> NB! This script assumes that the base address for BAR0 in the HLT-RORC is FB400000. It also assumes that the PCI base address for the Vanguard local target memory is FD000000. 6. Choose <i>Exerciser -> Script -> Load</i> and enter testbench.scr. 7. Choose <i>Exerciser -> Target</i> and enable the local target memory. Check that the Memory Window Address is consistent with the memory addresses in the script file. 8. Enter F9 to start sampling on the PCI bus. Then enter F10 to run the exerciser script. The exerciser script now runs the same scenario as in the VHDL testbench. If the HLT-RORC-4 design is working, the analyzer should be triggered by the HLT-RORC writing bursts of data words to the local memory. 9. Enter Alt-F9 to halt the analyser after the analyzer has been been triggered. Then choose Exerciser -> Local -> Display to examine the data written to local target memory by HLT-RORC. ==Verifying the implementation with the software== NB! Step 1-2 can only be done by a user with root permission. The first steps should therefore be taken care of by the supervisor, so the students doing this exercise can jump directly to point 4. 1. To run the software, a kernel module called psi has to be inserted into the kernel. The PSI tar.gz file can be downloaded from http://www.kip.uni-heidelberg.de/ti/HLT/software/software.html. If you download PSI version 0.8.2 from august 2003, you will have to patch psi_mod.c to make it compile on newer kernels. A patchfile called psi_mod.patch is located in the HLT-RORC directory. Before compiling, remember to change the TOPDIR variable in the Makefile and remove -DWITHBIGPHYS if bigphys is not compiled into the kernel (and it probably isn't). Now you can install the module by entering directory psi-0.8.2\src\driver.linux and typing (in the following sequence): <PRE> make clean make module make install make dev (or typing manually mknod /dev/psi c 100 0) chmod 666 /dev/psi (to give normal users permission to access the device file) </PRE> The module can now be installed by typing <i>insmod psi.o</i> (You will need root permissions to do this. If you want to use my precompiled binaries instead of compiling yourself, make sure to boot up the computer with the 2.4.20custum-bigphys kernel. You can check which kernel is running by typing 'uname -a'.) Make sure that you are running with the same kernel when loading the module as when compiling the module, unless the modules wont work. To compile the PSI API, go to directory psi-0.8.2\src\libpsi.linux and type <i>make</i>. 2. Enter directory HLT-RORC/src. If necessary, you will have to edit Makefile and Rules.make before compiling. Then run <i>make all</i> followed by <i>make install</i>, <i>mknod /dev/irqsignal c 120 1</i> and <i>chmod 666 /dev/irqsignal</i>. Now you can insert the irqsignal module by typing <i>insmod irqsignal major=120</i>. 3. Enter directory HLT-RORC/example. Compile the included files by typing make generate_irq. Remember to change the PSIDIR variable in the Makefile before compiling. 4. Run the compiled program generate_irq. The program will set up the HLT-RORC card to start interrupt-driven DMA-transfers. A signal handler located in the generate_irq program will respond to the interrupts. The program can be terminated by pressing Ctrl-C. 5. To observe the transactions with the Vanguard Analyzer, use the same events and trigger conditions that were shown in the previous example. afb4282291b44c1bc8fbbb9c0e9c985d14c5878c 0 38 75 2009-02-19T07:59:31Z Nfyku 4 New page: =Laboratory exercise for building and simulating a simple CMOS inverter in Cadence Virtuoso== ==Starting up== To invoke Cadence Virtuoso, type the following from unix shell <PRE> ssh -X ... wikitext text/x-wiki =Laboratory exercise for building and simulating a simple CMOS inverter in Cadence Virtuoso== ==Starting up== To invoke Cadence Virtuoso, type the following from unix shell <PRE> ssh -X mikroserver2 source /prog/design_kits/cadence_init/cshrc.cadence.ams ams_cds -tech c35b4 -nologo -mode fb </PRE> Virtuoso Mixed Signal Design Environment should now start up: <img src="uploads/icms_uppstart.JPG" /> In the "icms" dialog box, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach an existing techfile". Then click the OK button. When asked for technology, choose TECH_C35B4. <img src="uploads/new_library.JPG" /> After successfully creating the new library, it is time to create your first design. In the "icms" dialog box, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name (for example "torcell", as I did). You must also specify which library the design belongs to, and here you specify the library that you have just created (in my case, TORLIB). <img src="uploads/create_new_file.JPG" /> Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: <img src="uploads/virtuoso_schematic_editor.JPG" /> ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos" (for n-type transistor) or "pmos" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. <img src="uploads/library_browser.JPG" /> 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. For the transistors, set the "Width" and "Lenght" properties to "4u" and "1u". For the pmos transistor, set the "Model name" property to "modp". For the nmos transistor, set the "Model name" property to "modn". As we will see later, the "modn" and "modp" models correspond to SPICE simulation models used by the simulator in the Analog Environment. <img src="uploads/edit_object_properties.JPG" /> <img src="uploads/edit_object_prop_pmos.JPG" /> 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Tools > Analog Environment". The "Virtuoso Analog Environment" should now come up: <img src="uploads/analog_env_1.JPG" /> ==Simulate the design== 8. Choose "Setup > Simulator/Directory/Host" and set spectreS as your simulator. 9. Choose "Setup > Model Path" and add directory "/prog/hk_37/spectreS/c35/cmos53/tm" to your model path. 10. Choose "Simulation > Netlist > Create Raw". 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. <img src="uploads/choosing_analyses.JPG" /> <img src="uploads/select_comp_parameter.JPG" /> The analog environment should now look like this: <img src="uploads/analog_env_2.JPG" /> 13. Choose "Simulation > Run". 14. After the simulation has completed, choose "Results > Plot Outputs > DC". The outputs should look like this: <img src="uploads/plot_output_dc.JPG" /> To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generate a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. <img src="uploads/add_pin.JPG" /> After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". <img src="uploads/create_cellview_from_cellview.JPG" /> Now press OK: <img src="uploads/symbol_generation_options.JPG" /> Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: <img src="uploads/symbol_editor.JPG" /> Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. 0c105b00b8f05aec69c228971980344dda63502d 76 2009-02-19T08:00:26Z Nfyku 4 wikitext text/x-wiki =Building and simulating a simple CMOS inverter in Cadence Virtuoso= ==Starting up== To invoke Cadence Virtuoso, type the following from unix shell <PRE> ssh -X mikroserver2 source /prog/design_kits/cadence_init/cshrc.cadence.ams ams_cds -tech c35b4 -nologo -mode fb </PRE> Virtuoso Mixed Signal Design Environment should now start up: <img src="uploads/icms_uppstart.JPG" /> In the "icms" dialog box, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach an existing techfile". Then click the OK button. When asked for technology, choose TECH_C35B4. <img src="uploads/new_library.JPG" /> After successfully creating the new library, it is time to create your first design. In the "icms" dialog box, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name (for example "torcell", as I did). You must also specify which library the design belongs to, and here you specify the library that you have just created (in my case, TORLIB). <img src="uploads/create_new_file.JPG" /> Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: <img src="uploads/virtuoso_schematic_editor.JPG" /> ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos" (for n-type transistor) or "pmos" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. <img src="uploads/library_browser.JPG" /> 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. For the transistors, set the "Width" and "Lenght" properties to "4u" and "1u". For the pmos transistor, set the "Model name" property to "modp". For the nmos transistor, set the "Model name" property to "modn". As we will see later, the "modn" and "modp" models correspond to SPICE simulation models used by the simulator in the Analog Environment. <img src="uploads/edit_object_properties.JPG" /> <img src="uploads/edit_object_prop_pmos.JPG" /> 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Tools > Analog Environment". The "Virtuoso Analog Environment" should now come up: <img src="uploads/analog_env_1.JPG" /> ==Simulating the design== 8. Choose "Setup > Simulator/Directory/Host" and set spectreS as your simulator. 9. Choose "Setup > Model Path" and add directory "/prog/hk_37/spectreS/c35/cmos53/tm" to your model path. 10. Choose "Simulation > Netlist > Create Raw". 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. <img src="uploads/choosing_analyses.JPG" /> <img src="uploads/select_comp_parameter.JPG" /> The analog environment should now look like this: <img src="uploads/analog_env_2.JPG" /> 13. Choose "Simulation > Run". 14. After the simulation has completed, choose "Results > Plot Outputs > DC". The outputs should look like this: <img src="uploads/plot_output_dc.JPG" /> To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. <img src="uploads/add_pin.JPG" /> After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". <img src="uploads/create_cellview_from_cellview.JPG" /> Now press OK: <img src="uploads/symbol_generation_options.JPG" /> Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: <img src="uploads/symbol_editor.JPG" /> Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. 459ba6611ee8c06f4d1f5387f63eec65e857ae24 6 40 79 2009-02-19T08:44:53Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 41 83 2009-02-19T08:56:58Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 42 85 2009-02-19T08:58:36Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 43 86 2009-02-19T08:58:58Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 44 87 2009-02-19T08:59:16Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 45 88 2009-02-19T08:59:35Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 46 89 2009-02-19T08:59:54Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 47 90 2009-02-19T09:00:14Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 48 92 2009-02-19T09:00:56Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 21 99 2009-02-19T09:39:06Z Nfyku 4 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [[http://www.uib.no/personer/Kjetil.Ullaland Kjetil]] * Engineers: Dominik, Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. 126589cd153dc0749234d021e7cb131b1baa4d47 100 2009-02-19T09:39:52Z Nfyku 4 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: Dominik, Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. 89ea5bd8bc069697be9072877b535b89c155dc63 101 2009-02-19T09:49:00Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: Dominik, Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] 951752b1f59908e2cc1ce6bfedc25982f4175756 0 21 102 2009-02-19T10:08:21Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] 4811aadedb2582c746d84537939fdb344619ff68 103 2009-02-19T10:23:57Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] [[Picture galley for talks, etc...]] f50e570b67efa78323c35bf949f3e83b4a7f52d2 104 2009-02-19T10:29:34Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] 4811aadedb2582c746d84537939fdb344619ff68 105 2009-02-19T10:33:18Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] * [[whateveryouwant]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] 7676a02ea319607fe445aba7109e1e0a0d2cba98 106 2009-02-19T10:33:43Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] e18c3b92b9ff917fcb82b815405a13a2d949eb17 107 2009-02-19T13:28:53Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * Hege ... ac58e078835ef422981e5b54cb8e89bd7911347e 115 2009-02-19T15:27:31Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * Hege ... [[Category:Detector lab]] 77b5e091f0fd10025a3554382f0cb8c336976cb3 0 23 108 2009-02-19T13:30:00Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... 439ace0c5c304212e74161bc613f425fe1272b3e 129 2009-02-20T10:21:55Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... [[Category:Detector lab]] d23588623ba439471f0116a09c80098c15510c12 0 49 109 2009-02-19T14:16:43Z Ift 1 New page: her kan en teste ut wikitext text/x-wiki her kan en teste ut a396161c571c0f5d4425d45d5666c08ecf3c2f93 110 2009-02-19T14:18:15Z Ift 1 wikitext text/x-wiki her kan en teste ut [[Category:Test]] f2c5d781af9f3ed5d47b6205f78628ae33f0aacb 0 1 111 2009-02-19T14:23:37Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] == Getting started == Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. * [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 55c85c5ffddf44dbc63313f421864587f0d59c0b 124 2009-02-20T07:20:44Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] == Komme i gang == * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide|Bruksanvisning for in Mediawiki] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] b471034872aadff7cacf64875045b08d31fa2a6d 125 2009-02-20T07:21:11Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] == Komme i gang == * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 6516cd50d14cc1f7719d867bc4583a3e754a088a 0 3 112 2009-02-19T14:48:45Z Nfyku 4 wikitext text/x-wiki == Overview == The Busy Box is located in the DAQ Counting Room. Its purpose is to halt the data taking when the system is saturated with event data. When the multievent buffers in the Front End Electronics run full, the Busy Box asserts a busy-signal to the Local Trigger Unit which halts the issuing of new triggers. The the busy-signal will be deasserted once there are available buffers. To calculate the number of used mulitevent buffers the Busy Box listens to the trigger system to see which events have been triggered, and then poll all the DRORCs to see which events have been transfered to DAQ. === Download Section === [[Category:Alice]] 6e3f3e8c2376af20dc986affc265fb34728ab8d8 113 2009-02-19T14:50:46Z Nfyku 4 wikitext text/x-wiki == Overview == The Busy Box is located in the DAQ Counting Room. Its purpose is to halt the data taking when the system is saturated with event data. When the multievent buffers in the Front End Electronics run full, the Busy Box asserts a busy-signal to the Local Trigger Unit which halts the issuing of new triggers. The the busy-signal will be deasserted once there are available buffers. To calculate the number of used mulitevent buffers the Busy Box listens to the trigger system to see which events have been triggered, and then poll all the DRORCs to see which events have been transfered to DAQ. === Download Section === [[Category:Trigger]] 4bcb5088b5e982031ebe11c4038a1b21dc8c30ed 114 2009-02-19T15:07:04Z Rbo021 13 wikitext text/x-wiki == Overview == The Busy Box is located in the DAQ Counting Room. Its purpose is to halt the data taking when the system is saturated with event data. When the multievent buffers in the Front End Electronics run full, the Busy Box asserts a busy-signal to the Local Trigger Unit which halts the issuing of new triggers. The the busy-signal will be deasserted once there are available buffers. To calculate the number of used mulitevent buffers the Busy Box listens to the trigger system to see which events have been triggered, and then poll all the DRORCs to see which events have been transfered to DAQ. === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Category:Trigger]] 87bdc380f3e99df38c2f2cea37fca1f1f3a1b61e 116 2009-02-19T19:13:13Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one of these conditions is true: Buffers in Fec are full, upon receiving a trigger sequence from TTC or when the TTC sends a global reset to the Fee. The BusyBox is located in the DAQ counting rom. === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Category:Trigger]] 5317d69cad52e7694dd7ecddc4e7027e07ce7f99 118 2009-02-19T19:21:58Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one of these conditions is true: Buffers in Fec are full, upon receiving a trigger sequence from TTC or when the TTC sends a global reset to the Fee. The BusyBox is located in the DAQ counting rom. === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Category:Trigger]] 58777e99ed6b43bc791c771d6d2ff90796a315bd 120 2009-02-19T19:24:25Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one of these conditions is true: Buffers in Fec are full, upon receiving a trigger sequence from TTC or when the TTC sends a global reset to the Fee. The BusyBox is located in the DAQ counting rom. === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Trigger]] ee3f6445cba18ab11d5c51066305067adc3c05a4 122 2009-02-19T19:27:25Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one of these conditions is true: Buffers in Fec are full, upon receiving a trigger sequence from TTC or when the TTC sends a global reset to the Fee. The BusyBox is located in the DAQ counting rom. === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Trigger]] bb9b85e330cd7137417ddb3c37bfcba648e6fc90 6 50 117 2009-02-19T19:17:37Z Rbo021 13 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 51 119 2009-02-19T19:22:23Z Rbo021 13 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 25 123 2009-02-20T07:07:34Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphuics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System [[Category:Mikroelektronikk]] 323300863d0069026c2f4b62fa15c59a6d43aa5c 0 4 126 2009-02-20T09:21:42Z Stud4729 6 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] <br><br> == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.2.bin armboot_v2.2.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3.bin armboot_v2.3.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://www.ift.uib.no/~alme/wiki/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://www.ift.uib.no/~alme/wiki/xilinx_hwicap.o xilinx_hwicap.o] | [http://www.ift.uib.no/~alme/wiki/loop.o loop.o] | [http://www.ift.uib.no/~alme/wiki/readme.txt readme.txt] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.4.bin armboot_v2.4.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.5.bin armboot_v2.5.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.6.bin armboot_v2.6.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.61.bin armboot_v2.61.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.62.bin armboot_v2.62.bin] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://www.ift.uib.no/~alme/wiki/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/~alme/wiki/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://www.ift.uib.no/~alme/wiki/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://www.ift.uib.no/~alme/wiki/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/~alme/wiki/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://www.ift.uib.no/~alme/wiki/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://www.ift.uib.no/~alme/wiki/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://www.ift.uib.no/~alme/wiki/vreg.jed vreg.jed]<br> ispVM System Project File: [http://www.ift.uib.no/~alme/wiki/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br><br> === Download Section === [http://www.ift.uib.no/~alme/wiki/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://www.ift.uib.no/~alme/wiki/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://www.ift.uib.no/~alme/wiki/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://www.ift.uib.no/~alme/wiki/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://www.ift.uib.no/~alme/wiki/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://www.ift.uib.no/~alme/wiki/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://www.ift.uib.no/~alme/wiki/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://www.ift.uib.no/~alme/wiki/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://www.ift.uib.no/~alme/wiki/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://www.ift.uib.no/~alme/wiki/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://www.ift.uib.no/~alme/wiki/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://www.ift.uib.no/~alme/wiki/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://www.ift.uib.no/~alme/wiki/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://www.ift.uib.no/~alme/wiki/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://www.ift.uib.no/~alme/wiki/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://www.ift.uib.no/~alme/wiki/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] <br><br> == Radiation related issues == TBA f82e6cda1045ada6f54059263e08559ad0cad1bd 0 22 127 2009-02-20T10:21:22Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET senter at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == Characterisation Cell == == Characterisation setup and results == [[Category:Detector lab]] 289bd6091e03e97912ef3e25e400685951e7a712 0 24 128 2009-02-20T10:21:39Z Dfe002 7 wikitext text/x-wiki == General information == Information about ILC, CALICE and calorimeter detectors can be found here: * http://ilcagenda.cern.ch/conferenceOtherViews.py?confId=1049&view=cdsagenda&showDate=all&showSession=all&detailLevel=contribution == Our projects == * About Calorimeter testbeam? * Calorimeter Measurement System? [[Category:Detector lab]] 56746246b340f3dbc1b4fc6edfc2acdd4a9f950e 0 53 130 2009-02-20T10:41:23Z Dfe002 7 New page: == Introduction == The DCS boards are designed to be connected to a server--or central node--through a network. This server will most importantly be running the InterComLayer. However, the... wikitext text/x-wiki == Introduction == The DCS boards are designed to be connected to a server--or central node--through a network. This server will most importantly be running the InterComLayer. However, the network will also allow remote logon to the boards using SSH, as well as providing them with access to remote NFS-shares. The network is preferably set up and managed with central configuration tools, such as DHCP and DNS. Configuring each board locally will in most cases be very inconvenient, particuarly as all boards are supposed to be descriminated solely by their hardware board numbber--not by local configuration files. This page will outline how such a network is set up. == DHCP configuration == To reach the outside world, the DCS boards will need an IP-address. This they will obtain from the DHCP server. The first thing they do when they are woken up and want to set up their network interface, is to send a querry about it. The DHCP server can identify clients asking for IP-addresses on their hardware--or MAC--address. For networks based on Ethernet, this is always a unique 48 bit identifier. For the special case of the boards, the first 24 bits are 40:EA:54. The last 24 is the board number. In the setup we propose here, the board number will also be used as part of the IP-address and hostname. We will be using a private class A network, 10.0.0.0, allowing for 24 bits of client address space. 16 bits in the range 10.1.0.0 to 10.1.255.255 are reserved for the DCS boards. Each of them will have an etry in /etc/dhcpd.conf: host dcs0000 { hardware ethernet 40:EA:54:00:00:00; fixed-address 10.1.0.0; } Further, we reserve the range 10.0.1.0 to 10.0.1.255 for registered devices (servers, workstations, laptops, etc.), and 10.0.2.0 to 10.0.2.255 for unregistered devices. The former will be registered in dehcpd.conf, hence given fixed IP-addresses, while the later are not, and will have to suffice with random addresses in the mentioned range. Any but the most temporary devices are encouraged to be registered. The DHCP-server in this example will also act as a gateway to the outside world. We will discuss this in greater detail later. Here we will only cover the implications for the configuration of DHCP. The sever will thus have two network interfaces--one for the private net, and one for the external. Addresses for the external will be provided by another server with which we are only concerned as a mere client. Our DHCP-server can, of cource, in principle hand out addresses on both interfaces--definitely not what we want. Thus, the important issue here is to prevent this from ever happening. As we are a normal client on the external network, we do in principle not even know anything of the parameters of the external network until we have received this information from the DHCP-server of the external network. However, it is in most cases safe to assume the subnet and netmask will reamin the same as long as we connect to the same physical network. This information is all we need. We define this network in dhcpd.conf, but without any pool of addresses to hand out, effectively dissableing our server from answering dhcp-requests on this interface. subnet 128.141.0.0 netmask 255.255.0.0 { not authoritative; } In our case the IP-address of gateway and DHCP-, DNS- and time-server is all 10.10.10.10. One may choose to spread these services to several machines, but for a small test-network like this, performance and up-time are not a great concern. In a final setup, it might be a consideration, though. We have defined these servies as options in the begining if the file. The essential sections now become like this: # DHCP set-up for DCS private network ddns-update-style none; subnet 10.0.0.0 netmask 255.0.0.0 { authoritative; allow booting; allow bootp; default-lease-time 3600; max-lease-time 7200; ddns-update-style none; #Get hostname from host entries # use-host-decl-names on; #Get hostnames from DNS get-lease-hostnames on; option domain-name "feenet"; option routers 10.10.10.10; option domain-name-servers 10.10.10.10; option time-servers 10.10.10.10; option ntp-servers 10.10.10.10; option nntp-server 10.10.10.10; option broadcast-address 10.255.255.255; option subnet-mask 255.0.0.0; pool { #Reserved for registered devices - not DCS boards! range 10.0.1.0 10.0.1.255; deny unknown-clients; boot-unknown-clients off; } pool { #Reserved for _not_ registered devices - not DCS boards! range 10.0.2.0 10.0.2.255; allow unknown-clients; boot-unknown-clients on; } pool { #Reserved for DCS boards - must be registered! range 10.1.0.0 10.1.255.255; deny unknown-clients; boot-unknown-clients off; } } subnet 128.141.0.0 netmask 255.255.0.0 { not authoritative; } group { host dcs0000 { hardware ethernet 40:EA:54:00:00:00; fixed-address 10.1.0.0; } host dcs0001 { hardware ethernet 40:EA:54:00:00:01; fixed-address 10.1.0.1; } } The entries for most of the DCS boards have been excluded in a effort to save space. A complete, working file (tested on SLC3) can be found on [http://www.ift.uib.no/~dagtl/dhcpd.conf http://www.ift.uib.no/~dagtl/dhcpd.conf]. For details concerning configuring the DHCP-server, please refer to "man 5 dhcpd.conf", "man dhcpd" and "man dhcp-options". == DNS configuration == As we know, all devics on a IP-network is identified by its IP-address. This is a numeric reference. While computers generally prefer this naming scheme, the same can not be said on the account of human beings, we prefer names that make "sense". The purpose of the DNS server is to map such "sane names" to IP-addresses--and vice versa. As the name imply, the DNS is centered around ''domains''. They are organized into a hierachy. For our small network, we will only explore a small fraction of the capabilities of the DNS. We will only have one domain, to be called ''feenet''. The main file to configure is /etc/named.conf. We will have to add two more sections to it: zone "feenet" { type master; file "feenet.zone"; }; zone "10.in-addr.arpa" { type master; file "10.in-addr.arpa.zone"; }; Further, the two files feenet.zone and 10.in-addr.arpa.zone have to be created. They shall be located at the rather awkward directory /var/named/chroot/var/named/. The first will handle the forward address resolution, i.e. names to numbers, while the last will take care of the reverse address resolution--numbers to names. It is important that these two files are kept consistent; so that names and numbers have a one-to-one relation! Without forther delay we will present them in order: $TTL 86400 @ IN SOA feenet. root.master.feenet. ( 16 ; serial 28800 ; refresh 14400 ; retry 3600000 ; expire 86400 ; ttl ) IN NS master.feenet. master IN A 10.10.10.10 dimdns IN CNAME master.feenet. tpc-fee_0_02_1 IN A 10.1.0.0 dcs0000 IN CNAME tpc-fee_0_02_1.feenet. dcs0001 IN A 10.1.0.1 and: $TTL 86400 @ IN SOA feenet. root.master.feenet. ( 12 ; serial 28800 ; refresh 14400 ; retry 3600000 ; expire 86400 ; ttl ) IN NS master.feenet. 10.10.10 IN PTR master.feenet. 0.0.1 IN PTR dcs0000.feenet. 1.0.1 IN PTR dcs0001.feenet. Once again, we have only included the essential head section, including the first few clients. The mayority of the clients are left out, as they are a mere repetition of the first. The complete files are available from [http://www.ift.uib.no/~dagtl/feenet.zone http://www.ift.uib.no/~dagtl/feenet.zone] and [http://www.ift.uib.no/~dagtl/10.in-addr.arpa.zone http://www.ift.uib.no/~dagtl/10.in-addr.arpa.zone]. Links to these two files has to be present in /var/named. If we take a closer look at the dhcpd.conf file, we notice it has been set up to obtain the host names from the DNS server. Alternatively, it can use the name provided for each separate host. However, this last approach will put us in the trouble of manually keeping the the DNS and DHCP host name configurations synchronized, whereas the initially suggested method will only require updates to be made to the DNS. We can also provide the DCS boards with aliases. For example, DCS borad number 0000, with IP address 10.1.0.0, has been given the name tpc-fee_0_02_1.feenet as its "real" name, and dcs0000.feenet as an alias. The first name is based on its geographical location in the TPC detector, wheras the second is derived from the board number. We can choose to address it using the name we at any given time find most convenient. It is important to point out that only the real name will be returned on reverse name lookups. The name of the FeeServer running on the DCS board will be the same as the board's geographical name, or more precicely, the geographical name ''is'' the FeeServer name. The purpose of using this as the main name, is to allow the name of the FeeServer to be set from the host name. We want the DCS boards to be completely configured from a server. This is an easy way to ''transfer'' the name to the DCS board. Further information on configuring DNS can be found in "man 5 named.conf" and "man dhcpd". === DNS entry generation === In order to simplify the DNS configuration the entries can be generated by the script ''names-feenet.sh''. The script can be downloaded from the [[DCS Download#Network setup Tools | download page]]. Usage: <tt>names-feenet.sh [OPTION] [configuration file]</tt> The script was written for the TPC setup, so all the default values concern the TPC. All values can be changed be command line parameters in order to customize the output. The routing can either be created from a configuration file (see below for format) or by looping over the geographical address range or board number range. ==== General Options ==== --configure-named configure the name deamon, root priviledges required --add-configuration add the configuration to the existing, by default all all DCS board entries are deleted from the existing configuration. --print-names print hostname table to stdout --print-backrouting print back routing table to stdout --enumerate simply enumerate the boards without building hostnames with geographical address --file=<file path> read configuration from file ==== Detector layout options ==== The hostnames are built from 3-dimensional geographical addresses, e.g. <tt>tpc-fee_0_04_3</tt>. The number of boards in each direction can be specified by the --nof[X,Y,Z] option --nofX=<x> TPC default 2 --nofY=<y> TPC default 18 --nofZ=<z> TPC default 6 The number of digits for each coordinate. Missing digits are filled with preceeding 0's. --digitsX=<d> TPC default 1 --digitsY=<d> TPC default 2 --digitsZ=<d> TPC default 1 Range of board numbers: specify the first and/or the last board. --min-boardno default 1 --max-boardno default unlimited --basename=<name> TPC default: tpc-fee --defaultname=<name> default: dcs Board enumeration skips the generation of the geographical addresses and generates just names with the default name --enumerate Network settings --netaddr=<address> network base address, default 10.0.0.0 --netmask=<mask> network mask, default 255.0.0.0 ==== Format of the configuration file ==== The configuration file is a simple text file, each line contains board number and the 3 coordinates. Comments can be included as usual by marking with '#'. # sample configuration for the TPC # boardno side sector partition 11 1 6 4 1 1 0 5 10 0 0 0 12 0 1 5 13 1 7 3 105 0 9 5 ==== Examples ==== [tpcfee01] ~ > names-feenet.sh --print-names --nofX=1 --nofY=1 tpc-fee_0_00_0 IN A 10.1.0.1 tpc-fee_0_00_1 IN A 10.1.0.2 tpc-fee_0_00_2 IN A 10.1.0.3 tpc-fee_0_00_3 IN A 10.1.0.4 tpc-fee_0_00_4 IN A 10.1.0.5 tpc-fee_0_00_5 IN A 10.1.0.6 dcs0001 IN CNAME tpc-fee_0_00_0 dcs0002 IN CNAME tpc-fee_0_00_1 dcs0003 IN CNAME tpc-fee_0_00_2 dcs0004 IN CNAME tpc-fee_0_00_3 dcs0005 IN CNAME tpc-fee_0_00_4 dcs0006 IN CNAME tpc-fee_0_00_5 [tpcfee01] ~ > names-feenet.sh --print-names --enumerate --min-boardno=65 --max-boardno=70 dcs0065 IN A 10.1.0.65 dcs0066 IN A 10.1.0.66 dcs0067 IN A 10.1.0.67 dcs0068 IN A 10.1.0.68 dcs0069 IN A 10.1.0.69 dcs0070 IN A 10.1.0.70 [tpcfee01] ~ > names-feenet.sh --print-names --basename=phos-fee --nofX=1 --nofY=1 --nofZ=4 --digitsY=1 --min-boardno=128 phos-fee_0_0_0 IN A 10.1.0.128 phos-fee_0_0_1 IN A 10.1.0.129 phos-fee_0_0_2 IN A 10.1.0.130 phos-fee_0_0_3 IN A 10.1.0.131 dcs0128 IN CNAME phos-fee_0_0_0 dcs0129 IN CNAME phos-fee_0_0_1 dcs0130 IN CNAME phos-fee_0_0_2 dcs0131 IN CNAME phos-fee_0_0_3 [tpcfee01] ~ > names-feenet.sh --print-names /tmp/configuration.txt tpc-fee_0_00_0 IN A 10.1.0.10 tpc-fee_0_01_5 IN A 10.1.0.12 tpc-fee_0_09_5 IN A 10.1.0.105 tpc-fee_1_00_5 IN A 10.1.0.1 tpc-fee_1_06_4 IN A 10.1.0.11 tpc-fee_1_07_3 IN A 10.1.0.13 dcs0001 IN CNAME tpc-fee_1_00_5 dcs0010 IN CNAME tpc-fee_0_00_0 dcs0011 IN CNAME tpc-fee_1_06_4 dcs0012 IN CNAME tpc-fee_0_01_5 dcs0013 IN CNAME tpc-fee_1_07_3 dcs0105 IN CNAME tpc-fee_0_09_5 == NFS configuration == We have to provide the DCS boards with disk space shared over the network. The purpose of this is twofold. Firstly, the flash memory occupied by the Linux systems on the DCS boards has a very limited capacity--only 8 megabytes. This will allow for the core system, but is marginal for storing FeeServer and log files. Secondly, flash memory is weakened for each write cycle. It is therefore desireable to reduce write operations to a minimum. This is particuarly true for the log files, which are constantly updated. Two directores should be provided, one with read-write (rw) access, and one read-only (ro). The FeeServer and other binaries/files the DCS bords are supposed ''not'' to write to should go in the ro-directory. Log files and similar files should be placed in the rw directory. As the ro directory we use /nfs_export/fee-net/, and as rw we use /dcs-share. A separate directory for the log files is provided as a subdirectory: /dcs-share/fee-log. The totally different locations of the ro and rw directories might seem odd. This is partly due to historical reasons (the rw directory was early introduced for developent, the ro was introduced when "order" was needed), and partly practical (the rw is much more frequently accessed during debug/development than the ro). Everybody has to be given all rights to the /dcs-share and /dcs-share/fee-log directories. The configuration of the NFS shares are made in the /etc/exports file: /dcs-share 10.0.0.0/255.0.0.0(rw,sync,no_wdelay,all_squash) /nfs_export/fee-net 10.0.0.0/255.0.0.0(ro,sync,no_wdelay,all_squash) The file is also available from [http://www.ift.uib.no/~dagtl/exports http://www.ift.uib.no/~dagtl/exports]. During init, the DCS boards will try to run a startup file for the FeeServer from the /nfs_exports/fee-net directory. It is thus important that the directory is populated properly with these files. They can be downloded from [http://www.ift.uib.no/~dagtl/fee.tgz http://www.ift.uib.no/~dagtl/fee.tgz]. == NAT configuration == NAT and IP forwarding will make the external network (Internet) accessible from the DCS network. The DCS netwok is however not accessible from the Internet. The DCS borads and other computers on the DCS network is "hiding" behind the gateway, from the outside it appears as if all requests originate from the gateway. For the computers on the inside, at the other hand, will not notice the precence of the gateway. NAT and IP forwarding is configured using IPTABLES. A simple script will set ip up appropriately, assuming eth0 is Internet, and eth1 DCS network: #!/bin/bash iptables --flush iptables --table nat --flush iptables --delete-chain iptables --table nat --delete-chain iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE iptables --append FORWARD --in-interface eth1 -j ACCEPT echo 1 > /proc/sys/net/ipv4/ip_forward The script can also be downloaded from [http://www.ift.uib.no/~dagtl/masq http://www.ift.uib.no/~dagtl/masq]. It is wise to load this script file on startup, preferably from /etc/rc.d/rc.local. [[Category:DCS]] 758ffc3f3d42a4a8c8e0d9ec1c2dc7abd97b75a5 0 54 131 2009-02-20T10:41:43Z Dfe002 7 New page: [[Category:DCS]] == General layout == The main idea is to provide a local network with all necessary services like DHCP, name server, time server aso. for the DCS boards. The name server ... wikitext text/x-wiki [[Category:DCS]] == General layout == The main idea is to provide a local network with all necessary services like DHCP, name server, time server aso. for the DCS boards. The name server running on the server machine provides the link between the board MAC address and the Board hostname. The server machine is connected via a second network to the CERN network and allows IP forwarding which means all machines on the local net have access to the outer network but not the other way. Logging on to the DCS boards is only possible from the server machine. The server machine runs also a DIM name server and has also the IntercomLayer installed. See below for a description how to start/configure. Please refer to the description of [[Setting up a local DCS network]] to get further information on the technical details. === DIM in distributed networks === In general it is possible to run the DIM name server on a gateway machine with to networks. The ports are connected to both networks. Since DIM relies on a direct connection between servers and clients, it is in a setup like this not possible to connect client and servers running on different sub networks. But is possible to have a relay on the gateway machine running, in out case this is the Intercom Layer. This was there principle, but we didn't get it running this way. We suspect that it is due to firewall rules since there gateway machine was registered as a portable and not as a fixed machine. This will change. So far the Windows machine running PVSS must thus be connected to the local network. === Naming scheme of the DCS boards === Currently the name and dhcp servers can provide hostnames/ ip addresses to the boards 061 to about 250. The default name is like ''dcs0061''. In order to introduce a geographic naming scheme the Boards will be named tpc-fee_<side>_<sector>_<partition> e.g. tpc-fee_0_09_03 Currently the DCS boards 61 to 69 get some arbitrary names tpc-fee_*_*_*. The hostname dcs0xxx can still be used to log on. == Accounts on the master node == A local user '''fee''' can be used for general purpose tasks like sending commands to the FeeServers (e.g. configuration files) or monitor the DIM system, ask Dag, Roberto or me for the password. In addition we will enable a couple of CERN accounts in order to give access to developers. == Network disks == The master provides network disks for the DCS boards. The /dcs-share folder on the master is mounted on /dcs-share on all the boards. The directory is mounted in read/write mode. In order to give write access also to the boards you have to make sure that the access rights for the certain sub-directory is set to rwx for all access groups. == DIM setup == === DIM name server === Choose ''dimdns'' as DIM_DNS_NODE on the local network. Choose the name of the server machine (e.g. tpcfee02.cern.ch) in order to access it from the outside. The latter has to be tested so far but it was confirmed by the DIM developers that this should work. === Looking at the system with a DIM tool === On the master just type ''dimInformationDisplay'' and you will get the unix DIM monitoring tool. Choose View -> All servers ==== Investigating services provided by the Server ==== in order to display all servers known to the system. By right click on the server icon you can choose ''Services'' and you will get a window with the list of the services provided by the server. Select e.g XX_TEMP which is the temperature of FEC XX and press ''View''. Press ''Subscribe'' in the window popping up. '''Note''': a value -2000 -2E+02 means ''no link'', which could be that the FEC is in state off (service XX_STATE is 0) ==== Limitations ==== The Dim Information Display can only show one value at a time. So, this is only suitable for debugging. The full monitoring will be done from PVSS. == The Intercom Layer == When logged on to the master node, start the Intercom Layer by typing startInterComLayer This will start the ICL in the current directory. The ICL will look for the following configuration files in the rundir: Profile.txt Servers.txt Services.txt The ''startInterComLayer'' command is based on the default TPC configuration files, which contain all the 216 servers. Several options can be used to customize the configuration: * '''--help''': print a command description * '''--stdconf''': run in the default configuration * '''--server=<pattern>''': run with a sub-set of the standard configuration. ''pattern'' can be used to select some servers from the default configuration. The wildcard '*' can be used for group addressing. If no server of the default configuration matches the pattern, the pattern is interpreted as server name. Multiple invocations of the ''--server'' option specify a list of servers * '''--rundir=<dirname>''': specify the rundir, the default dir is <tt>/tmp/${USER}/ICL-rundir</tt>. # start only for server tpc-fee_0_00_0 startInterComLayer --server='tpc-fee_0_00_0' # start only for all server on side 1 startInterComLayer --server='tpc-fee_1_*_*' # start only for all server in sector 10 on side 0 startInterComLayer --server='tpc-fee_0_10_*' # start only for servers in sector 10 and 11 on side 0 startInterComLayer --server='tpc-fee_0_1[0,1]_*' # start only for servers dcs0070 and dcs0071 startInterComLayer --server=dcs0070 --server=dcs0071 To start it permanently in the background: screen -S InterComLayer startInterComLayer <options> & In the current configuration the ICL tries to connects to all servers following the naming scheme tpc-fee_*_*_*. For each it subscribes to the services * MAIN_STATE * XX_STATE * XX_TEMP * XX_AV * XX_AC * XX_DV * XX_DC, where XX denotes the FEC. Branch A FECs 00 to 12, Branch B FECs 16 to 27. === Stoping the InterComLayer === The ICL can be killed by any user by executing: sudo killInterComLayer == Stand alone FEC monitoring on the DCS board == A stand-alone monitoring script exploiting the rcu-sh can be used to read out Data Points from the Monitoring and Safety Module. After logon to a DCS board try: # gives you a help tpc-feemonitor.sh --help # reads default services on FEC A01 tpc-feemonitor.sh --fec=A01 # monitors default services on FEC A01 5 times with sleep of 10 sec tpc-feemonitor.sh --fec=A01 --loop=5 --sleep=10 # reads temperature on FEC A01 tpc-feemonitor.sh --fec=A01 --data-point=TEMP Unfortunately the script interpreter on the ARM linux is quite slow, so the processing takes a little while before the actual read-out starts. Taking all FECs is only suitable if you want to start a longer monitoring process. The tool can be used to create rcu-sh scripts for the read-out of individual or an assembly of FECs. This script can than simply be re-used on and on with the rcu-sh, e.g. rcu-sh b <script path> -s -l 5 -w 1 sec '''Note:''' The tool doesn't switch on the continuous conversion on the FEC board controllers. The default value for the TEMP data point i 40. If this doesn't change, you should suspect, that the continuous conversion is off. # broad-cast to all FECs to switch on continuous conversion rcu-sh w 0xc411 0x7ff == FeeServer == If the network disks can be mounted, the FeeServer starts at bootup. It gets the hostname of the board as server name. === Provided services === Each FeeServer publishes the following the services: * MAIN_STATE * XX_STATE * XX_TEMP * XX_AV * XX_AC * XX_DV * XX_DC, where XX denotes the FEC. Branch A FECs 00 to 12, Branch B FECs 16 to 27. A FEC can be activated or deactivated by sending a high level command to the FeeServer: <fee> FEESVR_SET_FERO_DATA32 XX_STATE 0/1 </fee> This issues the ''FEESVR_SET_FERO_DATA'' command to the channel ''XX_STATE'', where ''XX'' has to be replaced by the FEC number and either 1 or 0 have to be used to enable and disable the FEC respectively. E.g. with the ''feeserver-ctrl'' echo '<fee> FEESVR_SET_FERO_DATA32 00_STATE 1 </fee>' | feeserver-ctrl --server tpc-fee_0_00_0 === Command line tool for sending of commands to a FeeServer === The ''feeserver-ctrl'' program is ment to test and debug the command execution on the FeeServer and the RCU sequencer. The tool reads from std input or a file and writes the result to std output or a file. Sending a configuration can be done by cat my_configuration | feeserver-ctrl --server <servername> # e.g. cat my_configuration | feeserver-ctrl --server tpc-fee_0_00_0 There are further options to send control commands to the FeeServer CE, try feeserver-ctrl --help feeserver-ctrl --ce-command help A few ''ce commands'' are picked out because of their importance during debugging, replace ''<server name>'' by the name of the server you want to connect to: # set the logging level of the ControlEngine # level 0: all # level 1: debug or higher (essentially the same as ''all'') # level 2: info or higher (default) # level 3: warning or higher feeserver-ctrl --server <server name> --ce-command CE_SET_LOGGING_LEVEL <level> # enable the service update feeserver-ctrl --server <server name> --ce-command CEDBG_EN_SERVICE_UPDATE 1 # disable the service update feeserver-ctrl --server <server name> --ce-command CEDBG_EN_SERVICE_UPDATE 0 === Log files of the FeeServers === The FeeServers publishs all messages on the message channel provided by the FEE API. In addition, logging messages are written to log files. They are available on the master node at /dcs-share/fee-log/<server name>. To listen for incoming messages do tail -f <file name> Setting the logging level of the FeeServer CE to a higher verbosity can be done by feeserver-ctrl --server <server name> --ce-command CE_SET_LOGGING_LEVEL 0 == Configuration of the Name server (DNS) == The DNS provides the hostname to the DCS board. The hostname is automatically used as FeeServer name. The hostnames are built from 3-dimensional geographical addresses, e.g. <tt>tpc-fee_0_04_3</tt>. To change the DNS configuration create a simple routing file containing board number and geographical address, e.g. # sample configuration for the TPC # boardno side sector partition 11 1 6 4 1 1 0 5 10 0 0 0 12 0 1 5 13 1 7 3 105 0 9 5 and configure the fee-network fee-names.sh --configure-named --add-configuration <config file> where ''<config file>'' has to be replaced by the file name. Further information can be found on the [[Setting up a local DCS network#DNS entry generation | DCS network]] page. == The RCU Gui == The RCU Gui developed by Christian H. Christensen is installed on the server machine. The Gui can connect to one FeeServer at a time, but several Gui's can be started at the same time. To start the Gui logon the server machine as user ''fee'' and type: rcugui fee://<servername> where ''<servername>'' has to be replaced by the name of the FeeServer you want to connect to, e.g. rcugui fee://dcs0080 The Gui provides comfortable access to the RCU memories as well as to the FECs. == The setup in the RCU lab == A laptop was used as server machine (master). The built-in network (eth0) is used for the uplink to the CERN network. The hostname is tpcfee02.cern.ch with IP address 137.138.54.220. == The setup for the clean room == An identical system was set up on a Linux PC providing to Ethernet interfaces. The machine has the hostname ''tpcfee01.cern.ch'' and is currently configured with IP :137.138.253.151 for the RCU lab. After completion and testing of the setup in the lab it will be moved to the clean room together with the big switch and one of the Windows machines from the DCS group intended to host the PVSS. 693c163b9c94efbcf6f354fef6a07aa8034b400f 0 55 132 2009-02-20T10:42:02Z Dfe002 7 New page: [[Category:DCS]] back to:[[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] This page explains the different components and tools which exist in... wikitext text/x-wiki [[Category:DCS]] back to:[[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] This page explains the different components and tools which exist in the FeeCom chain and how to run them. Those are in particular: __TOC__ == DIM Name Server == A dedicated DIM name-server takes control over all the running clients, servers and their services available in the system. Each server registers at startup all its services and command channels. For a client the location of a server is transparent. === How to get the software === Take the latest package from [http://dim.web.cern.ch/dim the dim web page] and follow the instructions to build the package for your platform. If you are running Linux and have problems to compile the package, the following might help you. === Compile the DIM package for Linux === Recently we encountered problems when compiling the DIM package. Although the environment variables had been set as proposed in the README*.txt, the setup script didn't work. The following recipe is working on Scientific Linux CERN, but for sure it should be the same for other distributions. * go to the directory of the dim package: cd <path to dim package> * set a couple of environment variables setenv DIMDIR `pwd`/linux setenv OS Linux setenv ODIR linux * compile the DIM library make -f makefile_dim === Starting the Name server === You might need to set the '''LD_LIBRARY_PATH''' variable to allow the system to find the dim shared library. cd <your path to the dim package> setenv LD_LIBRARY_PATH `pwd`/linux ./linux/dns You will get a message like PID 25703 - Wed Feb 15 13:51:15 2006 - DNS (pid 25703) starting up on kjekspc3.ift.uib.no == DIM Information Display == The DIM Information Display is a tool available for Linux which allows to monitor a DIM system. It is contained in the package you downloaded from the dim web page. * if you want to compile DID follow the instructions in the previous section and do in addition make -f makefile_did '''NOTE:'''The DID needs some libraries to link against which come usually with the X11 system, but on some distributions they are missing. Note that you can start the DID from another machine which might provide all the necessary libraries. Or think about a system update on your machine. Make sure that the Motif library is installed on your system. === Running the DIM Information Display === Again, you might need to set the '''LD_LIBRARY_PATH''' variable to allow the system to find the dim shared library. In addition, the '''DIM_DNS_NODE''' variable has to be set. This variable specifies the location where the DIM framework will look for the DIM Name Server. cd <your path to the dim package> setenv LD_LIBRARY_PATH `pwd`/linux setenv DIM_DNS_NODE <your dns host> ./linux/did Choose ''View -> All Servers'', now you should at least see the Name Server and your DIM servers if there are any. The documentation is not very extended, but you can get at least a glimpse at the [http://dim.web.cern.ch/dim/dim_tools.html dim web page]. == FeeServer == === Compilation === Download the latest version from then [[DCS Download | download page]]. The package relies on the usual Linux installation procedure ''configure'', ''make'' and ''make install''. Unpack the package and have a look into the '''README''' file. ''./configure --help'' and ''./configure --help=short'' provides information on the available options. Read more about the compilation process [[FeeServer#Compilation | here]]. ==== Compilation for the DCS board ==== You need a cross compiler and have to specify the following options to ''./configure'' * '''--host=arm'''(mandatory) * '''--prefix=<''dir''>'''(optional) specify the location where the executable will be copied with ''make install''. <br> You should consider to make this directory available to the DCS board via NFS. The default ''prefix'' is set to '''/nfs_export/dcscard/''${USER}'' ''' if this directory exists, otherwise to the current directory. Note that the files will be "installed" in '''<''prefix''>/bin''' or '''<''prefix''>/bin''' respectively. * '''--enable-<''detector''>''' for detector specific implementations ==== Compilation for normal PC Linux ==== ''configure'' - options * '''--enable-rcudummy'''(optional) this switches off all hardware access which might make life easier since you will not be bothered with bunches of error messages. A correct state handling will be implemented soon. * '''--enable-<''detector''>''' for detector specific implementations * '''--prefix=<''dir''>'''(optional) specify the location where the executable will be copied with ''make install''. <br> The default ''prefix'' is set to the current directory. Note that the files will be "installed" in '''<''prefix''>/bin''' or '''<''prefix''>/bin''' respectively. == InterComLayer == == PVSS == == U2F Library/API == === U2F API specification === === feeserver-ctrl command line tool === == RCU GUI == 0274bc6a9ea6c974e578c32cd801b3271fceaa8e 0 56 133 2009-02-20T10:44:18Z Dfe002 7 New page: [[Category:DCS]] [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] __TOC__ Since there are several packages required for a full DCS for Front-e... wikitext text/x-wiki [[Category:DCS]] [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] __TOC__ Since there are several packages required for a full DCS for Front-end electronics this page will accumulate versions which have been testet together. It's also reasonable to have only one place for downloading. == FeeServer == * [http://www.ift.uib.no/~kjeks/download/feeserver-0.9.1-rcu-0.9.2.tar.gz Version 0.9.1 with CE v 0.9.2 for RCU] ** core updated to 0.9.1 ** Logging *** INFO log level removed from core default log level *** log level for initialization is 'Info', after init changed to 'Warning' ** State Machines *** support for temporary states and guard structure added *** Handler for USER defined states added to dispatcher, dynamic transition handling implemented *** high-level commands CE_GET_TRANSITIONS, CE_GET_STATENAME, CE_GET_STATES, and CE_GET_STATE implemented for devices ** MsgBuffer access encapsulated completely in separate class DCSCMsgBuffer *** check of msgBufferInterface driver and intelligent handling of failures ** TPC/RCU *** MAIN state machine corrected according to the lates agreements *** ramping of FECs power on/off, FECs are switched with at least 1 second delay between each other *** apply final naming scheme for FECs if server name follows the naming rule TPC-FEE_x_y_z. *** ACTEL control device added ** Commands *** command set version 4 and 5 *** FEE_CONFIGURE improved: scanning of hardware address and printout, history of pending FEE_CONFIGURE commands ** Misc *** CE_FORCE_CH_UPDATE updates all services beginning with specified string *** service update is stopped during command execution * [http://www.ift.uib.no/~kjeks/download/feeserver-0.8-rcu-0.9.tar.gz Version 0.8.1 with CE v 0.9 for RCU] ** core updated to 0.8.1 ** CE++ interface finnished, fully object oriented CE ** TPC and PHOS CE converted to CE++ ** support and examples for TRD and FMD added ** CE publishs also int and char channels ** Sub-device handling implemented ** ACTIONS can be send to all sub-device state machines ** user defined states added to StateMachine, flexible translation scheme by CEStateMapper object ** rpm support added ** RCU CE *** detector flavors derive from RCU CE base class *** flexible branch layout *** detector specific FEC implementation inherits from FEC base class *** RCU registers published as int channels, currently AFL and ERRST *** switch for 5/8-bit SlowControl interface foreseen, 8-bit access has to be implemented * [http://www.ift.uib.no/~kjeks/download/feeserver-0.7-rcu-0.8.5.tar.gz Version 0.7.6 with CE v 0.8.5 for RCU] ** conversion to feeserver core version 0.7.6 ** command set version 3: access commands for all RCU registers added ** file descriptor leak in shell program execution fixed ** benchmark output enabled by ''--enable-benchmark'' ** FEC simulation implemented, enabled by ''--enable-fecsim'' ** all probing for RCU firmware features and FEC configuration is disabled by default and can be enabled by ''--enable-auto-detection'' * [http://www.ift.uib.no/~kjeks/download/feeserver-0.7-rcu-0.8.tar.gz Version 0.7.3 with CE v 0.8 for RCU] ** CE converted to C++ ** base classes for state machines ** FEE_CONFIGURATION commands implemented ** high-level commands and actions implemented ** FeeServer used in TPC commissioning from May 2006 ** CE log messages both printed to std channels and sent as DIM messages * [http://www.ift.uib.no/~kjeks/download/feeserver-0.7-rcu-0.6.2.tar.gz Version 0.7.3 with CE v 0.6.2 for RCU] ** version of the DCS workshop March 06 ** '''Note:''' this version does not send any log messages from the ''ControlEngine'' through the DIM message channel (will be fixed in the next version). * [http://www.ift.uib.no/~kjeks/download/FeeServer-0.7-rcu-0.5.tar.gz Version 0.7.3 with CE v 0.5 for RCU] == FeeClient == * [http://www.ift.uib.no/~kjeks/download/feeclient-0.6.tar.gz Version 0.6] ** enhanced documentation ** basic structure: ''core,'' ''sample client'', ''utilities'' ** '''NOTE:''' The ''FeeClientLimImp'' class has been renamed to ''FeeSampleClient'' ** support for further CE commands added to ''feeserver-ctrl'' ** [http://www.ift.uib.no/~kjeks/download/feeclient-0.6-doc.tar.gz Documentation of Version 0.6] ** [http://www.ift.uib.no/~kjeks/doc/feeclient Online Documentation of Version 0.6] * [http://www.ift.uib.no/~kjeks/download/feeclient-0.5.tar.gz Version 0.5] ** Includes updated version of FeeClientLibImp, capable of communicating simultaneously with several FeeServers even if they respond in different order than called. ** View README file on how to install package. == InterComLayer == * [http://www.ift.uib.no/~kjeks/download/interComLayer-0.5.tbz Version 0.5.0] ** Note: there have been changes in the naming of the services, FeeServer versions 0.7-rcu-0.5 or later require at least version v0.4.3 of the InterComLayer * [http://www.ift.uib.no/~kjeks/download/interComLayer_v042.tar.gz Version 0.4.2] ** this version of the InterComLayer works only with FeeServers 0.7-rcu-0.4 === Tools === * [http://www.ift.uib.no/~kjeks/download/startInterComLayer.tgz startInterComLayer]: helper script for startup and on-the-fly changes of a default configuration. Description can be found on the [[Setup of low-level DCS for TPC Front-end electronics#The Intercom Layer | TPC FEE setup]] page. == ARM cross compiler == * [http://www.ift.uib.no/~kjeks/download/arm-uclibc-3.3.1-toolchain.tar.bz2 precompiled package] to be unpacked to <i>/usr/local/arm</i> == DCS board software for TPC == === RCU shell === To update the rcu shell on the DCS board unpack the corresponding tar file, e.g. #logon to dcs board cd /tmp wget http://www.ift.uib.no/~kjeks/download/rcu-sh-1.4.tar.gz tar xzvf rcu-sh-1.4.tar.gz -C / * [http://www.ift.uib.no/~kjeks/download/rcu-sh-1.4.tar.gz rcu-sh version 1.4] ** new DCS board firmware v2.2 supported *** writing of compressed data *** faster flash access * [http://www.ift.uib.no/~dominik/files/rcu-sh-1.5.tar.gz rcu-sh 1.5] ** requires driver version 0.6 ** lock functionality enhanced ==== Source code ==== The source code of rcu-sh, drivers and additional RCU Flash memory tools. * [http://www.ift.uib.no/~kjeks/download/rculinux-1.5.tar.gz package version 1.5] === RCU bus driver === To update the rcubus driver on the DCS board unpack the corresponding tar file, e.g. #logon to dcs board cd /tmp wget http://www.ift.uib.no/~kjeks/download/rcubus_driver_0.6-debug.tgz tar xzvf rcubus_driver_0.6-debug.tgz -C / * [http://www.ift.uib.no/~kjeks/download/rcubus_driver_0.6-debug.tgz rcubus_driver version 0.6 debug] ** enhanced and fixed lock functionality === DCS board scripts === * [http://www.ift.uib.no/~kjeks/download/tpc-fecmonitor.sh.tgz tpc-fecmonitor.sh] - rcu-sh script generator for TPC Front-end card monitoring == Network setup Tools == === Name server === * [http://www.ift.uib.no/~kjeks/download/names-feenet.sh.tgz names-feenet.sh] - name server routing generator == Download Archive == Check the [[Download Archive]] if you are interested in ancient stuff. --------- --------- == RCU Gui == [http://cholm.web.cern.ch/cholm/alice/fee/#rcuxx The RCU Gui written by Christian H. Chritensen] == FeeCom software == The core FeeCom software can be found at * [https://www.ztt.fh-worms.de/download/alice/ FeeCom software] can be found at the ZTT (for login contact the ZTT). == Further information and downloads for the ARM linux on the DCS board == * [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html Armlinux] for the DCS board by Tobias Krawutschke b62d45ee2c44a5d14a8b9de17ec0d8e9836b45ef 0 57 134 2009-02-20T10:44:36Z Dfe002 7 New page: [[Category:DCS]] [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] __TOC__ == General DCS board related questions == === What species of Linux i... wikitext text/x-wiki [[Category:DCS]] [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] __TOC__ == General DCS board related questions == === What species of Linux is running on the DCS board? === The Linux on the DCS board is a compilation of several projects suited for embedded systems * Kernel: [http://www.arm.linux.org.uk/ The ARM Linux Project] with minor changes. Kernel version 2.4.21 * regular programs: [http://www.busybox.net/about.html BusyBox], The Swiss Army Knife of Embedded Linux * C library: [http://uclibc.org/about.html uClibc] === I cant find common UNIX tools like diff on the DCS board === The version of busybox included into the linux during the early days of the DCS board doesn't support commands like od, cmp and diff. An additional package contains those three programs. To install them * download the package [http://www.ift.uib.no/~kjeks/download/dcsboard-addon-0.1.tar.gz dcsboard-addon] * unzip it to the root (/) directory (the archive contains all necessary sub folders) * e.g. on the DCS board do wget -P /tmp/ http://www.ift.uib.no/~kjeks/download/dcsboard-addon-0.1.tar.gz tar xzvf /tmp/dcsboard-addon-0.1.tar.gz -C / === Can I compile programs on the DCS board? === No, the Linux on the DCS board is a light-weight operating system which just provides the environment to run programs. Of course, this could be a compiler, but this doesn't make sense. One uses a cross compiler on another system to build the executables. === What is a cross compiler? === Cross compiling means to compile and build on a build system which is different from the system the program has to run on. Each cpu architecture has its own instruction set, binary format aso. The compiler translates the program source code into machine code for a certain architecture. Most embedded systems (like the one on the DCS board) don't provide fully functional operating systems. The use of a cross compiler is a convenient tool to create executables on another workstation. The Arm Linux on the DCS board uses gcc 3.3.1 configured for arm-uclibc. === How do I install a cross compiler and use it? === The Arm Linux on the DCS board is compiled with gcc 3.3.1 and uses uclibc as standard library. This page gives just a short recipe for the installation. For further details look at the [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html DCS board Arm Linux] page. To install the compiler you have two possibilities: * The precompiled package<br>There is a precompiled package configured for <i>uclibc</i> and <i>/usr/local/arm/3.3.1</i>. The compiler has to be exactly at that place. *# Download the [http://www.ift.uib.no/~kjeks/download/arm-uclibc-3.3.1-toolchain.tar.bz2 package]. *# Create a folder /usr/local/arm on your build machine or ask your system administrator to do it for you and give you write access. *# Unpack the package tar xvjkf arm-uclibc-3.3.1-toolchain.tar.bz2 -C /usr/local/arm * Install the gcc from scratch and configure it for arm linux. There is a helper script on the [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html DCS board Arm Linux] page. In both cases you must add the compilers's binary directory to your search path. For the first it is <i>/usr/local/arm/3.3.1/bin</i>, e.g. # c-shell setenv PATH ${PATH}:/usr/local/arm/3.3.1/bin # or # bash export PATH=${PATH}:/usr/local/arm/3.3.1/bin === How can I copy the executable to the DCS board? === <b>scp <filename> root@<address of the board>:/tmp</b><br> This will place the file in the /tmp directory of the board. The better solution is to mount a network directory. Note that the /tmp directory on the board is erased each time it boots since it is not located in the flash ram. === Where are all the files from the /tmp directory after reboot === You should not place any files you want to keep in the /tmp folder since this is areased after reboot. === How do I mount a network directory on the DCS board? === This is two-fold. An extern machine has to provide the directory and the DCS board has to mount it. # The server, can be any Linux machine the board has access to<br>Usually you need root access to configure the server. #* nfs deamon has to run on the host machine #** start nfs service: <b>/sbin/service nfs start</b> #** stop nfs service: <b>/sbin/service nfs stop</b> #** status information: <b>/sbin/service nfs status</b> #* configure the allowed export directories in <b>/etc/exports</b>, e.g. with a line like<br><b>/nfs_export/dcscard dcs0034(rw)</b><br>the directory '/nfs_export/dcscard' can be mounted by the machine 'dcs0034' in read-write mode #* finally after altering <b>/etc/exports</b> you might have to run <b>exportfs -a</b> in order to update the list of NFS exported file systems # The client, i.e. the DCS board #* create a directory <b>/mnt</b> if it does not exist #* use the command <b>/usr/local/sbin/nfsmount</b> to mount the network directory, e.g.<br><b>/usr/local/sbin/nfsmount <host>:/nfs_export/dcscard /mnt rw</b> #* Of course you can name the mountpoint on the DCS board whatever you want === I can not write to my network directory=== check if * the server allows write access (/etc/exportfs) * the DCS board mounts the network disc in read-write mode * the permissions for the directory on the server allow write access, keep in mind that the applications on the DCS board are running under a different user than usually you are on the host machine, and thus 'others' have to have write access === How can I connect to the DCS board from a Windows computer by using the serial line? === First of all you need to have the proper serial line connector cable [http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/mechanic/RS232cable01.gif Schematics]. In one side of the connector there is a small red dot. This should be connected to the connector on the short egde next to the ttc-fiber connector. Connect it to a free com-port on your pc.<br> In windows use 'hyperterminal' with the following settings: <br> ''Baud Rate:'' 57600<br> ''Data Bits:'' 8<br> ''Parity:'' None<br> ''Stop Bits:'' 1<br> ''Flow Control:'' None == InterComLayer related questions == === What is the InterComLayer? === === Where do I have to install/run the InterComLayer? === === What tools can I use to monitor the DIM framework? === == FeeServer related questions == === What is a FeeServer? === === What is the ControlEngine? === == rcu shell related questions == The sections will be filled as the questions come in a1ad31f24db382789dbd8727d47f11434f16a6ea 0 58 135 2009-02-20T10:44:58Z Dfe002 7 New page: [[Category:DCS]] back to:[[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] :: [[FeeServer]] This page describes the ControlEngine for the TPC Re... wikitext text/x-wiki [[Category:DCS]] back to:[[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] :: [[FeeServer]] This page describes the ControlEngine for the TPC Readout Control Unit. The RCU is also used for the PHOS detector. Later there will be dedicated pages for each detector as well which will contain the specialities. __TOC__ == Building a FeeServer == Please refer to the [[FeeServer#Compilation | FeeServer page]] for help on building a FeeServer. == Command Handling: the Issue method == The CE API provides the method 'issue' to receive commands from a DIM client. The function gets a block of data, where the first 4 bytes represent a [[RCU_ControlEngine#Command header format | 32 bit header]] specifying the type of the command. Each command has to be terminated by a [[RCU_ControlEngine#Command tailer | 32 bit tailer]], containing an and marker and the version no of the command definition. '''Note:'''The architecture of the ARM linux is ''little endian'', which means the least significant byte comes first. === Command header format === The general structure of the header word is: * Bit 32 - 28 | 27 - 24 | 23 - 16 | 15 -0 * 1 1 1 1 cmd id sub id parameter * ^------- 16 bit user parameter passed to the handler function * ^----------------- 8 bit command sub id passed to the handler function * ^-------------------------- 4 bit command id switches to the handler function * ^------------------------------------- 4 bit code for FeeServer command A FeeServer command always starts with 0xf in Bit 27 to 32. Everything else is interpreted as encoded in the [[RCU_ControlEngine#The Message Buffer Format | Message Buffer Format]]. Bit 24 to 27 represent the command id. The sub id and the parameter are specific for each command group. So far the following command groups exist: * <b>0x1</b>: Control Engine Commands * <b>0x2</b>: Msg Buffer Interface Commands * <b>0x3</b>: RCU access commands * <b>0x4</b>: Command set for the RCU configuration * <b>0x5</b>: Setting of values to data point in the Front-end electronics * <b>0x6</b>: Data readout * <b>0x7</b>: Shell command execution * <b>0xa</b>: TPC commands * <b>0xb</b>: PHOS commands The global command scanning is handled by the function /******************************************************************************************* * global switch to the corresponding handlers */ int translateCommand(char* buffer, int size) The function is a switch to the specific handler functions, it extracts command id and the parameter from the header. The treatment of the parameter is up to the specific command. === The Message Buffer Format === The ''Message Buffer Interface'' is a memory mapped interface for the communication between DCSboard and RCU. The FeeServer treats all command blocks with Bits 28 to 31 of the Header word different from 0xf as encoded in the ''Message Buffer'' format and transferes them directly to the interface. [[DCS_board_tools#Message_Buffer_access_.28RCU_interface.29 | Message Buffer Interface specifications]] === Control Engine commands === /******************************************************************************************* * the commands concerning and explicitly handled by the CE */ int translateCeCommand(__u32 cmd, __u32 parameter, const char* pData, int iDataSize) The following ids are defined in rcu_issue.h FEESERVER_CE_CMD (0x01000000 | FEESERVER_CMD) {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Command Name ! style="background:#ffdead;" | Command Code ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Parameter ! style="background:#ffdead;" | # words in data buffer |- | CEDBG_SET_BUF_PRINT_SIZE | 0xf1010000 | set the maximum size for the command buffer debug print, default 0 | the maximum number of bytes for printout | 0 |- | CEDBG_USE_SINGLE_WRITE | 0xf1020000 | use single write/read for rcu memory writing | 0 = off, 1 = on | 0 |- | CEDBG_EN_SERVICE_UPDATE | 0xf1030000 | turn on/off the update of the services | 0 = off, 1 = on | |- | CEDBG_SET_SERVICE_DATA | 0xf1040000 | set the data of a service | bit 0-7 service no; bit 8-12 FEC no; bit 13=1 rcu register (FEC no not valid); parameter: 0x0 off, 0xffff all on, 0x<bitfield> selection on | 0 |- | CE_READ_DEFAULT_SERVICES | 0xf1050000 | returns a list of all possible services | | 0 |- | CE_READ_VALID_FECS | 0xf1060000 | returns a list of the valid Frontend cards | | 0 |- | CE_RELAX_CMD_VERS_CHECK | 0xf1070000 | relax the version checking for commands | 0 = off, 1 = on | 0 |} === Message Buffer Interface commands === /******************************************************************************************* * the commands concerning the message buffer access library */ int translateDcscCommand(__u32 cmd, __u32 parameter, const char* pData, int iDataSize) { The following ids are defined in rcu_issue.h FEESVR_DCSC_CMD (0x02000000 | FEESERVER_CMD) {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Command Name ! style="background:#ffdead;" | Command Code ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Parameter ! style="background:#ffdead;" | # words in data buffer |- | DCSC_SET_OPTION_FLAG | 0xf210000 | set a debug option flag of the dcscRCUaccess library | bitpattern, each bit=1 corresponds to an option flag to be set | 0 |- | DCSC_CLEAR_OPTION_FLAG | 0xf220000 | clear a debug option flag of the dcscRCUaccess library | bitpattern, each bit=1 corresponds to an option flag to be cleared | 0 |} === RCU commands === Per default the RCU functionality is enabled. It can be disabled by the <b>--enable-rcu=no</b> option during package configuration. int translateRcuCommand(__u32 cmd, __u32 parameter, const char* pData, int iDataSize) { The following ids are defined in rcu_issue.h FEESVR_CMD_RCU (0x03000000 | FEESERVER_CMD) {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Command Name ! style="background:#ffdead;" | Command Code ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Parameter ! style="background:#ffdead;" | Payload |- | RCU_EXEC | 0xf3010000 | send the execution command to run the sequence written to rcu instruction memory | ignored | 0 |- | RCU_STOP_EXEC | 0xf3020000 | stop the execution | ignored | 0 |- | RCU_WRITE_INSTRUCTION | 0xf3030000 | write to rcu instruction memory | number of 32 bit words | 32 bit data, count specified by parameter |- | RCU_EXEC_INSTRUCTION | 0xf3040000 | write to rcu instruction memory and send the execution command | number of 32 bit words | 32 bit data, count specified by parameter |- | RCU_WRITE_PATTERN8 | 0xf3050000 | write 8 bit data to rcu pattern memory | number of 8 bit words | (parameter + 3)/4 (data block has to be aligned to 4) |- | RCU_WRITE_PATTERN16 | 0xf3060000 | write 16 bit data to rcu pattern memory | number of 16 bit words | (parameter + 1)/2 (data block has to be aligned to 4) |- | RCU_WRITE_PATTERN32 | 0xf3070000 | write 32 bit data to rcu pattern memory | number of 32 bit words | 32 bit data, count specified by parameter |- | RCU_WRITE_PATTERN10 | 0xf3080000 | write 10 bit compressed data to rcu pattern memory, each 32-bit word of the data block contains 3 10-bit words | number of 10 bit words | (parameter + 2)/3 (data block has to be aligned to 4) |- | RCU_READ_INSTRUCTION | 0xf3090000 | read from rcu instruction memory | number of 32-bit words to read | 0 |- | RCU_READ_PATTERN | 0xf30a0000 | read from rcu pattern memory | number of 32-bit words to read | 0 |- | RCU_READ_MEMORY | 0xf30b0000 | read from rcu memory location | address in the RCU memory space | 0 |- | RCU_WRITE_MEMORY | 0xf30c0000 | write to rcu memory location | address in the RCU memory space | one 32 bit word |- | RCU_WRITE_RESULT | 0xf30d0000 | write to rcu result memory | number of 32-bit words to write | 32 bit data, count specified by parameter |- | RCU_READ_RESULT | 0xf30e0000 | read from rcu result memory | number of 32-bit words to read | 0 |- | RCU_WRITE_MEMBLOCK | 0xf3100000 | write to rcu memory - the first word specifies the address, data words are following | number of 32-bit words to write | one 32 bit address followd by 32 bit data, count specified by parameter |- | RCU_READ_MEMBLOCK | 0xf3110000 | read from rcu memory - the word in the data block is treated as address in RCU memory space | number of 32-bit words to read | one 32 bit address |} === Command set for the RCU configuration === This command set is intended to steer the firmware update and configuration for the RCU. So far not implemented. FEESVR_CMD_RCUCONF (0x04000000 | FEESERVER_CMD) {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Command Name ! style="background:#ffdead;" | Command Code ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Parameter ! style="background:#ffdead;" | # words in data buffer |- | RCU_WRITE_FPGA_CONF | 0xf4010000 | write a configuration to the RCU FPGA | | 0 |- | RCU_READ_FPGA_CONF | 0xf4020000 | read the configuration of the RCU FPGA | | 0 |- | RCU_WRITE_FLASH | 0xf4030000 | write a file to the Flash | | 0 |- | RCU_READ_FLASH | 0xf4040000 | write a file to the Flash | | 0 |} === Setting of data points of the Front-end electronics === Set the data for a corresponding service, the handler function has to be specified during the registration of the service. The payload is expected to be a 8, 16, or 32 bit value followed by the name of the corresponding service. The length of the string is specified as parameter in the lower 16 bit of the command header. Currently, the command block must be aligned to 4, add some NULL bytes to the name string to comply with that rule. FEESVR_SET_FERO_DATA (0x05000000 | FEESERVER_CMD) {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Command Name ! style="background:#ffdead;" | Command Code ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Parameter ! style="background:#ffdead;" | # words in data buffer |- | FEESVR_SET_FERO_DATA8 | 0xf5010000 | set 8 bit value to data point | length of zero terminated service name | (1+parameter + 3)/4 |- | FEESVR_SET_FERO_DATA16 | 0xf5020000 | set 16 bit value to data point | length of zero terminated service name | (2+parameter + 3)/4 |- | FEESVR_SET_FERO_DATA32 | 0xf5030000 | set 16 bit value to data point | length of zero terminated service name | (4+parameter + 3)/4 |- | FEESVR_SET_FERO_DFLOAT | 0xf5040000 | set float value to data point | length of zero terminated service name | (8+parameter + 3)/4 |} === Data readout from the rcu data buffer === This provides a low rate access to the events in the RC data buffer. FEESVR_CMD_DATA_RO (0x06000000 | FEESERVER_CMD) === shell command execution === This group of commands allows the execution of shell commands on the DCS board. The parameter, the lower 16 bit, gives the size of that command buffer in BYTE FEESVR_CMD_SHELL (0x07000000 | FEESERVER_CMD) {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Command Name ! style="background:#ffdead;" | Command Code ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Parameter ! style="background:#ffdead;" | # words in data buffer |- | FEESRV_EXECUTE_PGM | 0xf7010000 | execute a script/program on the DSC board | | the remaining data is interpreted as a char string containing shell command and arguments |- | FEESRV_EXECUTE_SCRIPT | 0xf7020000 | send a script down ans execute it | | the remaining data is interpreted as a char buffer containing the script |- | FEESRV_BINARY_PGM | 0xf7030000 | send a binary program to the DCS board and execute it | | the remaining data is interpreted as a char buffer which contains the binary program |- | FEESRV_RCUSH_SCRIPT | 0xf7040000 | send a script down and execute it with rcu-sh | | the remaining data is interpreted as a char buffer which contains the script |} === TPC commands === So far there are no specific commands for the TPC electronics. Everything is covered by the RCU functionality. A function call is forseen. The support has to be enabled by the <b>configure</b> option <b>- -enable-tpc</b>. Internally this is translated to the define <b>TPC</b>. All code has to be encapsulated by #ifdef TPC ... #endif Files: ce_tpc.c, ce_tpc.h int translateTpcCommand(__u32 cmd, __u32 parameter, const char* pData, int iDataSize) { === PHOS commands === The support has to be enabled by the <b>configure</b> option <b>- -enable-phos</b>. Internally this is translated to the define <b>PHOS</b>. All code has to be encapsulated by #ifdef PHOS ... #endif Files: ce_phos.c, ce_phos.h <br> Specific commands for the PHOS detector are handled by the function: int translatePhosCommand(__u32 cmd, __u32 parameter, const char* pData, int iDataSize) { === Command tailer === The upper two byte contain a 16 bit end marker (0xdd33) and the lower two byte a version number. #define CE_CMD_EM_MASK 0xffff0000 #define CE_CMD_VS_MASK 0x0000ffff #define CE_CMD_VERSION 0x0001 #define CE_CMD_ENDMARKER 0xdd330000 #define CE_CMD_TAILER (CE_CMD_ENDMARKER | CE_CMD_VERSION) == Services == The default configuration of the RCU ControlEngine contains both services which publish data points of the FEC's and services for data points of the RCU, e.g. the '''A'''ctive '''F'''ront-end card '''L'''ist. All services are published at startup. The configuration of FEC's is determined by the '''FEESERVER_FEC_MONITOR''' environment variable. The variable must be set appropriate to publish any data from FEC's. It contains a string of ''0'' and ''1'' describing subsequently the status of FEC's starting from no 1. Missing digits at the end are treated as 0. E.g. the following configuration enables the control of FEC #2 and #5 export FEESERVER_FEC_MONITOR=01001 Services without a link to the data point are set to -2000. This happens if a Front-end card is included into the CE but not active. Service channels have always the type ''float''. Even bitfields or hexadecimal numbers are sent as that type. === RCU data points === The complete list is still going to be defined. {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Default configuration ! style="background:#ffdead;" | Name ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Deadband ! style="background:#ffdead;" | Bitwidth ! style="background:#ffdead;" | Type ! style="background:#ffdead;" | Implemented |- align="center" | on || RCU_AFL || active Front-end card list || 0.5 || 32 || hex || -- |- align="center" | on || RCU_ERRST || status and error || 0.5 || 32 || hex || -- |- align="center" | on || RCU_TRCFG || trigger configuration and status || 0.5 || 32 || hex || -- |- align="center" | on || RCU_CNT || trigger count || 0.5 || 32 || hex || -- |- align="center" | on || RCU_RDO || Read-out list || 0.5 || 32 || hex || -- |} === FEC data points === The following table shows the services which are published by default for one Front-end card. Each data point is identified by a unique name and can provide two functionalities: * publishing of data point via a DIM service channel, for that purpose an ''update'' method has to be implemented which can access the hardware. * set data point via the Command '''FEESVR_SET_FERO_DATA''', the ''set'' method has to be implemented to access the hardware. The environment variable FEESERVER_SRV_ENABLE is forseen to override the standard selection of service channels. The default configuration is given in the table. The variable can contain a comma separated list of service names. {| border="1" cellpadding="5" cellspacing="0" align="center" |- ! style="background:#efefef;" | Default configuration ! style="background:#ffdead;" | Name ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Deadband ! style="background:#ffdead;" | Bitwidth ! style="background:#ffdead;" | Conversion factor ! style="background:#ffdead;" | Unit ! style="background:#ffdead;" | Implemented |- align="center" | on || T_TH || temperature threshold || 0.5 || 10 || 0.25 || oC || v0.2 |- align="center" | on || AC_TH || analog current threshold || 0.5 || 10 || 0.017 || A || v0.2 |- align="center" | on || AV_TH || analog voltage threshold || 0.5 || 10 || 0.0043 || V || v0.2 |- align="center" | on || DV_TH || digital voltage threshold || 0.5 || 10 || 0.0043 || V || v0.2 |- align="center" | on || DC_TH || digital current threshold || 0.5 || 10 || 0.03 || A || v0.2 |- align="center" | on || TEMP || temperature || 0.5 || 10 || 0.25 || oC || v0.2 |- align="center" | on || AV || analog voltage || 0.5 || 10 || 0.0043 || V || v0.2 |- align="center" | on || AC || analog current || 0.5 || 10 || 0.017 || A || v0.2 |- align="center" | on || DV || digital voltage || 0.5 || 10 || 0.0043 || V || v0.2 |- align="center" | on || DC || digital current || 0.5 || 10 || 0.03 || A || v0.2 |- align="center" | off || L1CNT || level 1 trigger count || 0.5 || 16 || 1.0 || || v0.2 |- align="center" | off || L2CNT || level 2 trigger count || 0.5 || 16 || 1.0 || || v0.2 |- align="center" | off || SCLKCNT || || 0.5 || 16 || 1.0 || || v0.2 |- align="center" | off || DSTBCNT || || 0.5 || 8 || 1.0 || || v0.2 |- align="center" | off || TSMWORD || || 0.5 || 9 || 1.0 || || v0.2 |- align="center" | off || USRATIO || || 0.5 || 16 || 1.0 || || v0.2 |- align="center" | off || CSR0 || BC control & status register 0 || 0.5 || 11 || 1.0 || || v0.2 |- align="center" | off || CSR1 || BC control & status register 1 || 0.5 || 14 || 1.0 || || v0.2 |- align="center" | off || CSR2 || BC control & status register 2 || 0.5 || 16 || 1.0 || || v0.2 |- align="center" | off || CSR3 || BC control & status register 3 || 0.5 || 16 || 1.0 || || v0.2 |} == States == The CE exports the following state channels: * one channel CE state: '''CE_STATE''' * one channel RCU state: '''RCU_STATE''' * one channel for each valid FEC: '''FECxx_STATE''' === States of the RCU === {| border="1" cellpadding="5" cellspacing="0" |- ! style="background:#ffdead;" | Name ! style="background:#ffdead;" | Code ! style="background:#ffdead;" | Description |- | RCU_OFF || align="right" | 1 | RCU is off |- | RCU_START || align="right" | 2 | RCU has been switched on |- | RCU_RAMP_DOWN || align="right" | 3 | ramping down |- | RCU_CONF-WAITING || align="right" | 10 | the RCU could not configure automatically after power on and there is no configuration file on the DCS board avaiable -> waiting for configuration |- | RCU_CONFIGURING || align="right" | 11 | the configuration is in progress |- | RCU_CONFIGURED || align="right" | 12 | RCU is configured, after the RCU_CONFIGURING state the CE switches to state RCU_CONFIGURED and tries to connect to the RCU |- | RCU_NOT_ACCESSIBLE || align="right" | 20 | configuration was finished but access could not be established |- | RCU_RUNNING || align="right" | 100 | RCU is running |- | RCU_CORRUPTED || align="right" | 200 | RCU corrupted; this state can have several reasons: the CE encounters some strange behaviour of the RCU and checks the configuration; the configuration watchdog encounters a configuration missmatch, the scrubbing process on the RCU encounters a non repairable malfunction |} Note: The states are currently under discussion === States of FEC's === {| border="1" cellpadding="5" cellspacing="0" |- ! style="background:#ffdead;" | Name ! style="background:#ffdead;" | Code ! style="background:#ffdead;" | Description |- | FEC_UNDEFINED || align="right" | 1 | FEC is invalid |- | FEC_OFF || align="right" | 2 | FEC is off |- | FEC_START || align="right" | 3 | FEC has been switched on |- | FEC_RAMP_DOWN || align="right" | 4 | ramping down |- | FEC_CONF-WAITING || align="right" | 10 | waiting for configuration |- | FEC_CONFIGURING || align="right" | 11 | configuration in progress |- | FEC_CONFIGURED || align="right" | 12 | FEC is configured |- | FEC_NOT_ACCESSIBLE || align="right" | 20 | not accessable |- | FEC_RUNNING || align="right" | 100 | FEC is running |- | FEC_CORRUPTED || align="right" | 200 | FEC corrupted |- | FEC_FAIL || align="right" | 201 | FEC failure reported from MSM |- | FEC_FATAL || align="right" | 202 | FEC fatal failure reported from MSM |} Note: The states are currently under discussion == [[The Actel software device in the FeeServer CE]] == The Actel softwaredevice has the task to control and monitor the operation of the Actel FPGA on the RCU. For more information visit the [[The Actel software device in the FeeServer CE]] page. == [[DCS Download]] == f8d36cd0d2d490cf274702bb57c65a97b70380da 0 59 136 2009-02-20T10:45:26Z Dfe002 7 New page: [[Category:DCS]] [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] == Overview == This sections covers the DCS board software for the TPC-like de... wikitext text/x-wiki [[Category:DCS]] [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] == Overview == This sections covers the DCS board software for the TPC-like detectors (so far TPC, PHOS, most likely FMD and EMCAL). Apart from the mentioned FeeServer there are some low level tools and interfaces. In fact, the FeeServer uses them. [[Image:DCSboard software components.png|thumb|none|600px|DCS board Software Components]] The DCS board communicates via two interfaces to the RCU board: # The Message Buffer Interface: used for most of the data tranfer between software and memory on the RCU # The Direct Bus Access: programming of RCU Flash Memory and FPGA Configuration Memory A driver (rcubus_driver) provides the access to the interfaces via the following devices. A C-interface (RCU interface) implements basic functionality for the Message Buffer Interface. It is used by both the RCU shell (low level tool) and the FeeServer == Access to the RCU == The figure illustrates the the available hardware interfaces: Message Buffer Interface and Direct Bus Access. [[Image:DCSboard-RCU interface.png|frame|none|Hardware interfaces between DCS board and RCU]] The data flow is controlled by lines in the Control Register: * Bit 7 Start Command * Bit 6 MIB multiplexer, read enable * Bit 0 Ready * Bit 5 Direct mode select The idea behind the Message Buffer Interface: * the interface moves some of the complexity to the firmware * decouples cpu from the communication task * block by block transfer * 2 Buffers for communication and one Control Register ** Message Input Buffer (MIB) ** Message Result Buffer (MRB) ** Control Register * basic sequence from software view ** write command sequence to MIB ** set 'execute' flag ** wait for the 'ready' flag ** read result and status In Direct Bus Access mode the driver (or a specific subdriver) takes control over the bus lines. == RCU bus driver == The following devices are available resp. are planned to be that: */dev/rcu/msgbuf message buffer interface */dev/rcu/fpga fpga configuration (under development) */dev/rcu/flash general flash memory access (under development) */dev/rcu/flash0 flash memory bank 0 (under development) */dev/rcu/flash1 flash memory bank 1 (under development) */dev/rcu/flash2 flash memory bank 2 (under development) */dev/rcu/flash3 flash memory bank 3 (under development) == Message Buffer access (RCU interface) == The Message Buffer interface is a memory mapped interface. A certain command sequence has to be written to the Message Input Buffer (MIB). A command sequence constists of a 32-bit '''header word''', the command words and a 32-bit '''marker word''' which terminates one ''sequence block''. Several ''sequence blocks'' can be grouped and are finally terminated by the '''End marker word'''. The structure is outlined in the following figure. [[Image:MsgBufferFormat.png|frame|none|Format of the Message Buffer input]] === Command ids === * Bit 5-0 of the header word {| border="1" cellpadding="5" cellspacing="0" |- ! style="background:#ffdead;" | Command Name ! style="background:#ffdead;" | Command Code ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Command words ! style="background:#ffdead;" | # command words |- | align="center" valign="top" | SINGLE_READ | valign="top" | 0x1 | valign="top" | a single read operation | align="center" | {| border="1" style="width:100px" |address |} | valign="top" | 1 |- | align="center" valign="top" | SINGLE_WRITE | valign="top" | 0x2 | valign="top" | a single write operation | align="center" | {| border="1" style="width:100px" |address |- |data |} | valign="top" | 2 |- | align="center" valign="top" | MULTI_READ | valign="top" | 0x3 | valign="top" | block read operation <br> The ''count'' parameter indicates the number of words of a certain format <br>(see [[DCS_board_tools#Control_bits_and_block_number | control bits]]) | align="center" | {| border="1" style="width:100px" |address |- |count |} | valign="top" | 2 |- | align="center" valign="top" | MULT_WRITE | valign="top" | 0x4 | valign="top" | block write operation <br> The ''count'' parameter indicates the number of words of a certain format <br>(see [[DCS_board_tools#Control_bits_and_block_number | control bits]]) | align="center" | {| border="1" style="width:100px" |address |- |count |- |data #1 |- | ... |- |data #n |} | valign="top" | 2 + # data words |- | align="center" valign="top" | RANDOM_READ | valign="top" | 0x5 | valign="top" | random read operation | align="center" | {| border="1" style="width:100px" |address #1 |- |address #2 |- | ... |- |address #n |} | valign="top" | number of addresses |- | align="center" valign="top" | RANDOM_WRITE | valign="top" | 0x6 | valign="top" | random write operation | align="center" | {| border="1" style="width:100px" |address #1 |- |data #1 |- |address #2 |- |data #2 |- | ... |- |address #n |- |data #n |} | valign="top" | 2 x number of addresses |- | align="center" valign="top" | FLASH_ERASEALL | valign="top" | 0x21 | valign="top" | erase the flash completely | align="center" | {| border="1" style="width:100px" |} | valign="top" | 0 |- | align="center" valign="top" | FLASH_ERASE_SEC | valign="top" | 0x22 | valign="top" | erase one sector of the flash | align="center" | {| border="1" style="width:100px" |address |} | valign="top" | 1 |- | align="center" valign="top" | FLASH_MULTI_ERASE | valign="top" | 0x24 | valign="top" | erase multiple sectors of the flash | align="center" | {| border="1" style="width:100px" |address |- |count |} | valign="top" | 2 |- | align="center" valign="top" | FLASH_READID | valign="top" | 0x28 | valign="top" | read the ID of the flash <br> 0 = Manufacturer ID / 1 = Device ID | align="center" | {| border="1" style="width:100px" |'0' or '1' |} | valign="top" | 1 |- | align="center" valign="top" | FLASH_RESET | valign="top" | 0x30 | valign="top" | reset the flash | align="center" | {| border="1" style="width:100px" |} | valign="top" | 0 |} === Word count === * Bit 15-6 of the header word <br> must contain the number of words between the '''Header''' end the '''Marker'''. === Block number === * Bit 23-16 of the header word <br> number of the current ''sequence block'' <br> The first block has number '''n-1''', the block number is decremented for the following blocks. The last block has block no '''0'''. If there is only one ''sequence block'', the block no bits are just zero. === Control bits and block number === * Bits 25-24 Data Format {| border="1" cellpadding="5" cellspacing="0" |- ! style="background:#ffdead;" | 25 - 25 ! style="background:#ffdead;" | Description ! style="background:#ffdead;" | Data Format |- | align="center" valign="top" | 0 0 | valign="top" | no compression | align="center" | {| border="1" style="width:400px" | style="border:0px" align="left" | 31 | style="border:0px" align="right" | 0 |- | colspan=2 align="center" | address |} |- | align="center" valign="top" | 0 1 | valign="top" | 2 x 16 bit words | align="center" | {| border="1" style="width:400px" | style="border:0px" align="left" | 31 | style="border:0px" align="right" | 16 | style="border:0px" align="left" | 15 | style="border:0px" align="right" | 0 |- | colspan=2 align="center" | address + 1 | colspan=2 align="center" | address |} |- | align="center" valign="top" | 1 0 | valign="top" | 3 x 10 bit words | align="center" | {| border="1" style="width:400px" | style="border:0px" align="left" | 29 | style="border:0px" align="right" | 20 | style="border:0px" align="left" | 19 | style="border:0px" align="right" | 10 | style="border:0px" align="left" | 9 | style="border:0px" align="right" | 0 |- | colspan=2 align="center" | address + 2 | colspan=2 align="center" | address + 1 | colspan=2 align="center" | address |} |- | align="center" valign="top" | 1 1 | valign="top" | 4 x 8 bit words | align="center" | {| border="1" style="width:400px" | style="border:0px" align="left" | 31 | style="border:0px" align="right" | 24 | style="border:0px" align="left" | 23 | style="border:0px" align="right" | 16 | style="border:0px" align="left" | 15 | style="border:0px" align="right" | 8 | style="border:0px" align="left" | 7 | style="border:0px" align="right" | 0 |- | colspan=2 align="center" | address + 3 | colspan=2 align="center" | address + 2 | colspan=2 align="center" | address + 1 | colspan=2 align="center" | address |} |} === Version === * Bit 31 - 28 of header word <br> version of Message Buffer specification {| border="1" cellpadding="5" cellspacing="0" |- ! style="background:#ffdead;" | 31 - 28 ! style="background:#ffdead;" | |- | align="center" valign="top" | 0 x x x | version 1 (bit 31==0, other bits arbitrary) |- | align="center" valign="top" | 1 0 1 0 | version 2 |- | align="center" valign="top" | 1 0 1 1 | version 2.2 |- | align="center" valign="top" | 1 1 1 1 | FeeServer command (used outside the message buffer interface) |} === Result Format === {| border="1" cellpadding="5" cellspacing="0" |- ! style="background:#ffdead;" | Word # ! style="background:#ffdead;" | Description |- | align="center" valign="top" | 1 | align="center" | {| border="1" style="width:400px" | style="border:0px" align="left" | 31 | style="border:0px" align="right" | 16 | style="border:0px" align="left" | 15 | style="border:0px" align="right" | 0 |- | colspan=2 align="center" | | colspan=2 align="center" | Number of words |- | style="border:0px" colspan=4 align="center" valign="top" | Information Word |} |- | align="center" valign="top" | 2 | align="center" | {| border="1" style="width:400px" | style="border:0px" align="left" | 31 | style="border:0px" align="right" | 0 |- | colspan=2 align="center" | Status word |} |- | align="center" valign="top" | 3 - n | align="center" | {| border="1" style="width:400px" | style="border:0px" align="left" | 31 | style="border:0px" align="right" | 0 |- | colspan=2 align="center" | Data |} |} <pre> Status word: 0 - if no error Bit 15 set if any error Bit 0: missing marker Bit 1: missing end marker Bit 2: no target answer (something wrong with the RCU or not connected) Bit 3: no bus grant (no access to the bus on dcs board) Bit 5: old message buffer format (prior to v2 with rcu-sh version v1.0) </pre> === Examples === ==== Single read ==== from address 0x7000 {| border="1" cellpadding="5" cellspacing="0" | 0xA0000041 || Information word |- | 0x00007000 || address 0x7000 |- | 0xAA550000 || Block marker without Checksum |- | 0xDD330000 || End marker |} ==== Multiple write ==== 4 words starting at address 0x6800 {| border="1" cellpadding="5" cellspacing="0" |- | 0xA0000184 || Information word |- | 0x00006800 || address 0x6800 |- | 0x00000004 || 4 words to write |- | 0x0000AFFE || data word 1 |- | 0x0000D00F || data word 2 |- | 0x00001234 || data word 3 |- | 0x00005678 || data word 4 |- | 0xAA550000 || Block marker without Checksum |- | 0xDD330000 || End marker |} ==== Multiple write with 3x10 bit compress ==== 3x3 10bit words starting at address 0x7000 and finishing at 0x7008 {| border="1" cellpadding="5" cellspacing="0" |- | 0xA2000144 || Information word |- | 0x00007000 || address 0x6800 |- | 0x00000003 || 4 words to write |- | 0x2A995566 || data word 1 |- | 0x1EADBEEF || data word 2 |- | 0x01020202 || data word 3 |- | 0xAA550000 || Block marker without Checksum |- | 0xDD330000 || End marker |} ==== Flash Erase all ==== Erasing the complete content on the RCU Flash Memory {| border="1" cellpadding="5" cellspacing="0" |- | 0xA4000021 || Information word |- | 0xAA550000 || Block marker without Checksum |- | 0xDD330000 || End marker |} ==== Flash Erase Multiple Sectors ==== Erasing multiple subsequent sectors on the RCU Flash Memory {| border="1" cellpadding="5" cellspacing="0" |- | 0xA40000E4 || Information word |- | 0x003E8000 || Address of first sector (Word Address) |- | 0x00000004 || Number of sectors to Erase |- | 0xAA550000 || Block marker without Checksum |- | 0xDD330000 || End marker |} == RCU shell == The RCU Shell is a small command-line software for communcating with the firmware on the RCU motherboard. It is started by simply typing 'rcu-sh' at the command-line. This will bring you to the shell mode, where different types of commands can be executed.<br> The RCU motherboard can be operated in three different modes. # Memory mapped mode # Selectmap mode # Flash mode The default mode is memorymapped mode, which gives you direct memory access of the registers in the FPGAs on the RCU motherboard. <br> Flash mode gives the dcs board direct control of the flash memory on the RCU motherboard, while selectmap mode gives the dcs board direct control over the selectmap interface of the Xilinx Virtex-II on the RCU motherboard. === Memory mapped mode === === Selectmap mode === The Selectmap mode is enabled by typing: enter operation (h/i/q/r/w): selectmap enable or enter operation (h/i/q/r/w): sm e The following options is available: 1. Get help on commands: sm help 2. write to single address via the selectmap interface: sm w 0x[address] 0x[data] 3. read from single address via the selectmap interface: sm r 0x[address] 4. Abort ongoing operation on the Xilinx FPGA: sm abort === Flash mode === The flash mode is enabled by typing:<br> enter operation (h/i/q/r/w): flash enable The following options is available: <br> 1. Get help on commands: flash help 2. Write to single address in flash: flash write 0x[address] 0x[data] [num] num = number of sequental addresses to write the given data to 3. Write a file from a start address in the flash: flash write [-s] 0x[address] file [size] -s = byteswap enabled size = number of 16 bit words to write to the flash from beginning of file. 4. Erase complete flash: flash erase all 5. Erase sector: flash erase sec 0x[sector address] 6. Read single address from flash: flash read 0x[address] [num] num = number of sequental address to read from the given address. 7 Verify content of the flash memory: flash verify 0x[address] file Verifies that the content of the flash from the given address matches the content of the given file. == Connection to FeeServer == [[Image:DCSboard TPC-ControlEngine connection.png|frame|none|Connection of the FeeServer Control Engine (TPC version) to the Hardware interfaces]] 806e4363b7901bc55d7222e4a9147a60b03aa5dd 0 60 137 2009-02-20T10:46:12Z Dfe002 7 New page: [[Category:DCS]] back to:[[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] == Overview == ... (to be filled) == FeeServer Download == Curren... wikitext text/x-wiki [[Category:DCS]] back to:[[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] == Overview == ... (to be filled) == FeeServer Download == Current releases of the FeeServer with RCU-like ControlEngine (fits for '''TPC''' and '''PHOS''') are available from the [[DCS Download#FeeServer | Download page]]. Versions of the FeeServer core software can be downloaded from the [https://www.ztt.fh-worms.de/download/alice ZTT web pages]. This package only contains the FeeSever core, the needed [http://www.cern.ch/dim DIM framework] libraries and a dummy CE (something like a echo server), the real CE depends on the detector and requires the appropriated hardware). == Compilation == After unpacking the compressed archive (tar xzvf <filename> ) change to the directory. The package must be configured by running the ''./configure'' script, after configuration for the desired platform type ''make''. The script has several options: * '''--host <host environment>''' : selection of the cross compiler * '''--disable-rcu''' : RCU related functionality (in this wiki you will only find RCU-like FeeServers, so there is only the option to turn it off) * '''--enable-tpc''' : TPC related functionality (so far there is none, all is included in the RCU target) * '''--enable-phos''' : PHOS related functionality * '''--enable-mastermode''': Enable special features (e.g. shell command execution, FeeServer update) * '''--enable-rcudummy''' : Enable a dummy implementation of the RCU CE. This will skip all the hardware accesses. Try '''--help''' to get a comprehensive help or '''--help=short''' to get information on the package specific options. If you want to build the FeeServer for the armlinux on the DCS board you need a [[DCS FAQ#What is a cross compiler? | Cross Compiler]]. Currently arm-uclibc-gcc 3.3.1 is used. To configure the package for the cross compiler run the configure script like: ./configure --host arm make Be sure that the path of the cross compiler is added to the '''PATH''' environment variable ([[DCS FAQ#How do I install a cross compiler and use it? |more help]]). If you plan to compile the FeeServer core package please have a look into the README file which comes along with the package. == Preparation == To run the FeeServer on the DCS board copy it to the board wherever you want to have it. The second, strongly recommended, possibility is to mount a network disk on the board. The FeeServer package supports automatic copying to whatever folder through the standard ''make install'' command. The location can be specified by the '''--prefix''' option to the ''configure'' script. A few more variables have to be set: * '''DIM_DNS_NODE'''(mandatory) denotes the host where a ''Name Server'' for the DIM framework (''dns - DIM Name Server'') is running. * '''FEE_SERVER_NAME'''(mandatory) for the name of the FeeServer (as it will pop up in the DIM system ) * '''FEE_LOG_LEVEL'''(optional) default logging level of the FeeServer * '''FEESERVER_FEC_MONITOR'''(optional) specifies the valid FECs <br> its a string of '0' and '1', missing entries are set to 0, e.g. '01001' puts FEC 2 and 5 into the configuration '''!!! IMPORTANT !!! NOTE:''' Since version 0.7.0: The environment variable for the FeeServer name has changed to FEE_SERVER_NAME. (prior versions: DIM_SERVER_NAME) == Running the FeeServer == To execute FeeServer properly please follow these steps: * make sure that the dns for DIM is running on the machine you specified * !!! NEW !!! since version 0.7.0:<br> finally run ''sh startFeeServer.sh'' <br> This script starts the FeeServer and takes care of various features. The starting script also accepts an optional parameter: You can also set the FeeServer name by passing it to the starting script. The starting script automatically restarts the FeeServer, if it exits with an unknown error/exit value. For debugging purpose it is convenient to start the FeeServer directly like ''./feeserver''. In that case, the restart and update features will not work. == Important Notes == * for full functionality start the FeeServer only with the startFeeServer.sh script. * interface of FeeServer and CE changed in version 0.7.0 * The service name scheme for CE service has changed:<br>old style: ''servername/servicename'' -> new style: ''servername_servicename''<br> (These changes for ACK-, MSG- and Command-channel will follow.) * never turn on '''mastermode''' unless you are shure that your network is behind a firewall to avoid abuse. See also the README and ChangeLog - files of the FeeServer package. == ControlEngine guidelines == Following some notes, which should be taken account of when developing a ControlEngine. * We included a demo function for initializing an "Item" in our dummy CE. When writing an own CE, it is best copying and using this function in order to get a proper initialized "Item". * Don't use static created "Items", especially don't use static allocated memory for the "Item" names. This would case the clean up to hang and a proper exit would be no longer possible. * Please obey the DCS naming and numbering convention, when naming an "Item". more under: http://alicedcs.web.cern.ch/AliceDCS/ * Provide the "Items" with a default deadband. (Else the deadband will be 0, and the update rate would get to high -> to much traffic). * After the CE has been initialized, let this thread sleep for approx. 2-5 seconds (this gives the FeeServer time start the serving functionality inside the DIM framework). * In "cleanUpCE()", the CE don't need to clean and/or free "Items" and its members. (In fact it must not do it, this would crash the FeeServer during its cleanup.) * Don't call the createLogMessage() function during initializing the CE. (after the above mentioned sleep is fine). This service is only available after the DIM serving functionality has been started. * Be careful with sending log messages, especially in rapidly repeated checks/functions, this can pile up your log file extremely. Even consider carefully the specified log level; MSG_ALARM should be only for events, that could damage or destroy the system/hardware. * If, while testing, certain log messages of the CE don't appear, check the set log levels in FeeServer and InterComLayer. They may have filtered these messages. To set the default log level of the FeeServer, you can also use the environment variable FEE_LOG_LEVEL before starting the FeeServer. == ControlEngine implementations == * [[RCU ControlEngine | The ControlEngine for the RCU]] fe0954ba551015d763bb428913b7c6be74284804 0 61 138 2009-02-20T10:47:09Z Dfe002 7 New page: [[Category:DCS]] == Overview == ... (to be filled) == InterComLayer Download == Current versions of the InterComLayer software can be downloaded from the [https://www.ztt.fh-worms.de/do... wikitext text/x-wiki [[Category:DCS]] == Overview == ... (to be filled) == InterComLayer Download == Current versions of the InterComLayer software can be downloaded from the [https://www.ztt.fh-worms.de/download/alice ZTT webpages]. (Note: In order to use the access to an ORACLE DB, the DB client libs are also needed (can be found at the same location). The pthread libs for Windows and the [http://www.cern.ch/dim DIM framework] libs are already included). == Linux version == === Compilation === To compile the InterComLayer please follow these steps: - run ". setup.sh" or "source setup.sh" to prepare your shell (bash) - if you compile InterComLayer for the first time on your system: - run "make -f makefile_dim.linux" to compile the required DIM Library - run "make -f makefile_interCom.linux" to finally compile InterComLayer if you want to clean up your system: - run "make realclean -f makefile_dim.linux" to clean up DIM stuff - run "make clean -f makefile_interCom.linux" to clean up === Preparation === Before you start the InterComLayer you should adapt the Server.txt and Services.txt files to your needs. Server.txt contains the servername of the FeeServer, Services.txt the corresponding services. You have to make sure that the entered service name exactly looks like in DimTree or DID. The Property.txt file is used to change the behavior of the InterComLayer. You can change for example the way he published services or to which services he had to subscribe. The files are located in the linux folder. === Execution === To execute InterComLayer properly please follow these steps: - set DIM_DNS_NODE as environment variable to the dns for DIM - make sure that the dns for DIM is running on the machine you specified - make sure that all configuration files are available: - for servers / dcscards - for services / monitoring values - finally run interComLayer from the linux folder === Important Notes === Make sure that the setup.sh is executed only ONCE per shell! == Windows version == === Required Environment Variables === Set the following enviroment variables: DIM_DNS_NODE: tells on which host the dim name server is running TNS_ADMIN: tells the program where the database is located Path: add the path of the instant client libs (.dll's) to the PATH variable === Execution === - start the dim framework - The required file is contained in the dim directory/bin/dns.exe - you can controll that the dim name server starts via the dimtree tool in the same directory as dns.exe - change to the intercomlayer directory and enter the bin folder - start interComLayer.exe - the file to load Servernames calls Server.txt and for the Services calls Services.txt == Generell Note == See also the Readme - files in the current InterComLayer package. 08bae909eab21d5639392e1b42047a6b54f7c0c1 0 19 139 2009-02-20T10:49:06Z Dfe002 7 wikitext text/x-wiki for controlling the Active Partial Configuration solution __TOC__ == Overview == As described in [[Electronics for the Time Projection Chamber (TPC)]] the RCU has an Active Partial Reconfiguration (APR) network to reconfigure the Xilinx SRAM based FPGA in case there appear errors due to the radiation environment. This reconfiguration network includes some Flash memory and the Actel Flash based FPGA. The main task of the Actel software device is to monitor and control the operation of the Actel FPGA. For this reason it offers different services, as monitoring different registers that give information about the state of the hardware, to control the main operation modes of the Actel FPGA and to program the Flash memory for the Active Partial Reconfiguration solution to work. The Actel FPGA features three ways to configure the Xilinx Virtex-II Pro FPGA: *Initial Configuration : Configures the Xilinx Virtex-II Pro once during startup or on command from the DCS board. *Scrubbing : Continously overwrites the configuration memory of the Xilinx Virtex-II Pro, wether an error occured or not. *Frame by Frame readback and error correction : The Actel reads back the single configuration frame of the Xilinx Virtex and compares them to the configuration data stored in the Flash memory on the RCU. For this Active Partial Reconfiguration solution to work, the Flash memory has to be programmed with the correct firmware for the Xilinx FPGA. There are two ways on how to program the Flash memory: *The rcuflashprog command line tool *the here described Actel software device Information about the Actel FPGA and the rcuflashprog tool can be found at: [[Electronics for the Time Projection Chamber (TPC)#RCU Auxilliary FPGA Firmware for TPC and PHOS]] == The services == Some information that the Actel firmware provides is published to the upper layers, to monitor the status of the hardware and information about the number of errors due to the radiation environment.The Services provided are: *ACTEL_STATE :The int number representing the state. *ACTEL_STATENAME :The name of the current state, can be OFF | IDLE | SCRUBBING | READBACK | ERROR *ACTEL_FWVERSION :The firmware version of the Actel FPGA *ACTEL_STATUSREG :The status register of the Actel FPGA, Explanation: *ACTEL_ERRORREG :The error register of the Actel FPGA, Explanation: *ACTEL_CYCLECOUNTER :The number of cycles, how often complete Scrubbing or Frame by frame readback cycles were performed over all the Xilinx memory. *ACTEL_FRAMEERRORCOUNT :The number of errors corrected during Frame by frame readback. Expected are about 10-100 Errors for all 216 RCUs during a 4 hour run. == The statemachine == [[Image:actel_sm.jpg|thumb|350px|right|Sketch of the statemachine]] The statemachine for the Actel represents the main operating modes and adds states for error handling. The initial state is ''OFF/idle'' and during the transition to ''ON/configured'' the error and status register are cleared, the Flash is checked for proper configuration. When entering a mode of active partial reconfiguration, the counters are reset. During ''Scrubbing'' the Cyclecounter is updated, during ''Readback Verification'' also the Frameerrorcounter. In case slight errors occur during the operation, the ''Failure'' state is entered, from where an automatic recovery is attempted. In case this fails, or a severe error occurs, the ''Error'' state is entered, from where the Actel software device has to be reset manually. States can be changed using the fee-client lib. For test purpose, the states can be changed using the feeserver-ctrl command line tool, which uses the fee-client lib. Some commands: To enter the ''ON/configured'' state: echo '<fee>CE_TRIGGER_TRANSITION ACTEL switchon</fee>' | feeserver-ctrl --server TPC-FEE_0_13_1 To enter the ''Scrubbing'' state: echo '<fee>CE_TRIGGER_TRANSITION ACTEL GO_Scrubbing</fee>' | feeserver-ctrl --server TPC-FEE_0_13_1 To quit the scrubbing state: echo '<fee>CE_TRIGGER_TRANSITION ACTEL QUIT_Scrubbing</fee>' | feeserver-ctrl --server TPC-FEE_0_13_1 The other transitions:<br> To enter ''Readback Verification'': GO_Readback<br> To quit ''Readback Verification'': QUIT_Readback<br> To recover from the ''Error'' state: GO_Idle<br> To from ''ON/configured'' back to ''OFF/idle'': stop<br> == Programming the Flash == Programming the Flash on the RCU can be done in two ways: Either via the rcuflashprog command line tool from the DCS board console, or via the FeeServer using the feeserver-ctrl command line tool from a remote console. The usage of the rcuflashprog tool is briefly described (further down), and also in the Actel Usermanual. When programming the Flash via the FeeServer, binary command blocks, that hold the necessary data, have to be available. Since the Flash is divided in three parts (Initial Configuration, Scrubbing, Frame by Frame readback), there are three binary command blocks, each dedicated to one part of the Flash memory. The command blocks can then be send to the FeeServer via the fee-client lib. The feeserver-ctrl command line tool uses this lib. Commands can then be send in the following way: cat rcu_iconfflash.bin | feeserver-ctrl --server TPC_FEE_1_12_1 == Operating the Actel from PVSS == PVSS (Prozess Visualisierungs- und Steuerungssystem by ATM) is a commercial controlling software used to control the ALICE detector. Several panels have been developed by Christian Lippmann at Cern to control the APR solution on the RCU. [[Image:ACTEL_panel.png|thumb|500px|center|Actel state panel in PVSS]][[Image:ACTEL_panel2.jpg|thumb|500px|center|FEC panel with Actel controls in PVSS]] As its common in PVSS, a single RCU can be changed in its state by clicking on the according place on the end caps. To change the state of several RCUs, the '''FSM''' button in the top left corner, under the Alice logo can be used. == Upgrading the Flash memory with a new RCU firmware version == For now the feeserver-ctrl command line tool is needed. Later the binary command blocks will be stored in the configuration database and can be selected and send from there. For a full configuration, first the flash has to be erased, and then the three data block send: cat rcu_eraseflash.bin | feeserver-ctrl --server TPC_FEE_1_12_1 cat rcu_iconfflash.bin | feeserver-ctrl --server TPC_FEE_1_12_1 cat rcu_scrubflash.bin | feeserver-ctrl --server TPC_FEE_1_12_1 cat rcu_frameflash.bin | feeserver-ctrl --server TPC_FEE_1_12_1 Make sure to monitor the logfiles to see that everything went well. == Addendum == === How to use the framegen tool === The framegen is used to extract the configuration frames from the Xilinx Virtex-II Pro FPGA. When reading back the raw data, the framegen stores the frames as three versions: :*the raw framefile :*the read framefile (read header and read footer attached) :*the write framefile (write header and write footer attached) For this the header and footer files have to be given as arguments to the framegen, as well as the frameconfig file, which defines the frames to be read back. The syntax is: ''./framegen frames936.txt read_header read_footer write_header write_footer'' === How to use the rcuflashprog tool === The rcuflashprog tool is used to program the Flash memory on the RCU. A [http://web.ift.uib.no/~dominik/files/tools/flashconf_rcu190606bg3 sample config] file for the rcuflashprog tool: #enable erase enable_erase = true #init program file enable_icfile = true path_icfile = /mnt/kjekspc4/fee-net/rcu_fw/rcu_190606bg3/ name_icfile = rcu.bit startaddr_icfile = 8000h #scrubbing file enable_scfile = true path_scfile = /mnt/kjekspc4/fee-net/rcu_fw/rcu_190606bg3/ name_scfile = rcu_apr.bit startaddr_scfile = 60000h #frame file enable_frfiles = true path_frfiles = /mnt/kjekspc4/fee-net/rcu_fw/rcu_190606bg3/ name_readframefile = r_frame$.hex name_rawframefile = frame$.hex name_writeframefile = w_frame$.hex framesfile = frames936.txt startaddr_frfiles = 100000h frame_offset = 2h header_size_read = 1Bh footer_size_read = 0Bh In the ''enable_xxx'' config lines, the specific action can be chosen, wether the flash should be deleted prior to programming (recommended), and which of the flash parts (initial config, scrubbing or frame by frame readback) shoudl be programmed. For the initial config and the scrubbing, only one file each has to be supplied (the rcu.bit/rcu_apr.bit). For the frame section, all the single frames files are needed. The names of the frames have to be supplied in the 'framesfile'. The Xilinx Virtex-II Pro has 936 configurable frames, a file with all the 936 filenames can be downloaded [http://web.ift.uib.no/~dominik/files/tools/frames936.txt here]. A newer version of the rcuflashprog is under development, where the frame files are extracted from the rcu.bit file. === How to use the rcuflash_feessvr tool === The rcuflash_feesvr tool in the FeeServer package generates the binary command blocks that can be send to the FeeServer to program the Flash memory on the RCU. An [http://web.ift.uib.no/~dominik/files/tools/flashconf.conf example config] file for the rcuflash_feeserver tool looks like this: #FeeServer BLOB generator Configfile. #Do not edit unless you know what you are doing! #You have been warned.. #global option to enable BB_FLASH mode enable_bb_flash = true #enable erase enable_erase = true #init program file enable_icfile = true path_icfile = /home/dominik/src/work/FeeServer/build-dummy/tools/rcu_190606bg/ name_icfile = rcu.bit startaddr_icfile = 8000h BB_init_addr = 0h BB_init_info_addr = 3000h init_addr = 3f9000h init_info_addr = 3f9002 rcu_fw_version = 190606b #scrubbing file enable_scfile = true path_scfile = /home/dominik/src/work/FeeServer/build-dummy/tools/rcu_190606bg/ name_scfile = rcu_apr.bit startaddr_scfile = 60000h BB_scrub_addr = 1000h BB_scrub_info_addr = 4000h scrub_addr = 3fa000 scrub_info_addr = 3fa002 #frame file enable_frfiles = true path_frfiles = /home/dominik/src/work/FeeServer/build-dummy/tools/rcu_190606bg/ name_readframefile = r_frame$.hex name_rawframefile = frame$.hex name_writeframefile = w_frame$.hex framesfile = frames936.txt startaddr_frfiles = 100000h stopaddr_frfiles = 0h frame_offset = 2h #frame offset will have 00 appended: 2h -> 200h header_size_read = 1Bh footer_size_read = 0Bh BB_frame_addr = 2000h BB_frame_info_addr = 5000h frame_addr = 3fb000h frame_info_addr = 3fb002h ==== Composition of the Binary command blocks ==== The Binary command blocks contain information for the Actel software device in the FeeServer CE as well as the actual data that has to be programmed to the Flash. ===== Erase command ===== the Erase block only consists of the Header and Tailer, which tells the Actel softwaredevice to erase the Flash memory completely. {| border="1" cellspacing="0" cellpadding="5" align="center" ! Header ! CE_CMD_TAILER |- | 0xf405 0000 | 0xdd33 0000 |- |} ===== Initial Configuration Block ===== The initial configuration block contains the data of the 'rcu.bit' and some information about addresses and pointers in the flash. Furthermore the RCU firmware version is also coded into this command block and written on the Flash. In this way it can be checked which version of the RCU firmware is currently residing in the Flash memory device. This command block has about 560 kBytes in size. {| border="1" cellspacing="0" cellpadding="5" align="center" ! Header ! INIT_ADDR ! INIT_INFO_ADDR ! START_ADDR ! FILESIZE ! RCU_FW_VERSION ! DATA ! CE_CMD_TAILER |- | 0xf406 0000 | 0x0000 0000 | 0x0000 3000 | 0x0000 8000 | 0x0008 8e68 | 0x0190 606b | (rcu.bit) | 0xdd33 0000 |- |} ===== Scrubbing Block ===== The scrubbing command is similar to the initial configuration command block in its structure, the scrubbing command block just uses different addresses and data and omits the rcu firmware version number. This command block has about 340 kBytes in size. {| border="1" cellspacing="0" cellpadding="5" align="center" ! Header ! SCRUB_ADDR ! SCRUB_INFO_ADDR ! START_ADDR ! FILESIZE ! DATA ! CE_CMD_TAILER |- | 0xf407 0000 | 0x0000 1000 | 0x0000 4000 | 0x0006 0000 | 0x0005 37e0 | (rcu_apr.bit) | 0xdd33 0000 |- |} ===== Frame by Frame readback Block ===== The frame by frame readback block is the most complex and also biggest of the command blocks with its 1,33 MBytes. It holds all the necessary information to program the configuration frames of the Xilinx to the Flash. This is addresses, pointers and also 3 dedicated 'frame info registers', for forward compatibility the number of send frames is submitted as a parameter, which should make it easier to adapt the principle to later versions, maybe using the Xilinx Virtex-4, which has a different number of frames, and also a different size for the single frames. {| border="1" cellspacing="0" cellpadding="5" align="center" ! Header ! FRAME_OFFSET ! FRAME_ADDR ! FRAME_INFO_ADDR ! START_ADDR ! STOP_ADDR ! FRAME_INFO_REG1 ! FRAME_INFO_REG2 ! FRAME_INFO_REG3 ! SIZE_READ ! SIZE_WRITE ! Readframe Data ! Writeframe Data ! CE_CMD_TAILER |- | 0xf403 03a8 | 0x0000 0200 | 0x0000 2000 | 0x0000 5000 | 0x0010 0000 | 0x0000 0000 | 0x0000 2751 | 0x0000 d3cb | 0x0000 1b0b | 0x0000 01f8 | 0x0000 0398 | (NOF*Readframes) | (NOF*Writeframes) | 0xdd33 0000 |- |} The Header contains the number of frames (0x3a8 = 936). == Download Section == === The framegen tool:=== You can retrieve the framegen from the CVS, or download a compiled version [http://web.ift.uib.no/~dominik/files/tools/framegen here]. To get a version from the CVS, check out the ''dcsctools'' package, create a directory ''build-arm'' in the dcsctools directory, enter it, execute ''../.autotools/acsetup.sh'' there. Do a ''../configure --host=arm'' followed by the usual ''make''. The framegen can only be executed on the DCS board and needs a mounted NFS directory with write access. [http://web.ift.uib.no/~dominik/files/tools/framegen.tar.gz framegen.tar.gz package]. === The rcuflashprog :=== You can retrieve the rcuflashprog from the CVS, or download a compiled version [http://web.ift.uib.no/~dominik/files/tools/rcuflashprog here]. Additionally you need the rcuflashprog [http://web.ift.uib.no/~dominik/files/tools/flashconf_rcu190606bg3 config file]. To program the Xilinx configuration frames to the flash, a file that holds the block, major and minor numbers, a sample file with all 936 frames can be found [http://web.ift.uib.no/~dominik/files/tools/frames936.txt here]. [http://web.ift.uib.no/~dominik/files/tools/rcuflashprog.tar.gz rcuflashprog.tar.gz package]. <font color="red"> updated 22.04.08 </font> === The rcuflash_feesvr:=== You can retrieve the rcuflash_feesvr from the CVS, or download a compiled linux version [http://web.ift.uib.no/~dominik/files/tools/rcuflash_feesvr here]. Additionally you need the rcuflash_feesvr [http://web.ift.uib.no/~dominik/files/tools/flashconf.conf config file]. To define the frames which are to be put into the blobs, the [http://web.ift.uib.no/~dominik/files/tools/frames936.txt frames936.txt] is needed as well. The binary command blocks are generated from the single frame files. You can use the framegen tool to extract these... To compile an own version from the CVS, check out the ''FeeServer'' package and create a directory ''build-dummy'' in the FeeServer directory and enter it. Execute ''../.autotools/acsetup.sh'' there. Do a ''../configure'' followed by the usual ''make''. The rcuflash_feesvr is then located in ''tools/src'' and can be run on any normal linux machine. [http://web.ift.uib.no/~dominik/files/tools/rcuflash_feesvr.tar.gz rcuflash_feesvr.tar.gz package] === Binary command blocks:=== ==== For the RCU firmware V1 (FWV: 190606):==== :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606/rcu_eraseflash.bin rcu_eraseflash.bin] :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606/rcu_iconfflash.bin rcu_iconfflash.bin] :This FW version does not support scrubbing or Frame by Frame readback. :Also keep in mind that this version has a slight error, which makes it necessary to erase the Xilinx before Flash access is possible! :The flash with this firmware version on it shows "190606" in the flash firmware version register. :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606/rcu_fw_190606_bcmds.tar.gz rcu_fw_190606_bcmds.tar.gz package] ==== For the RCU firmware V1bg (FWV: 190606bg):==== :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg/rcu_eraseflash.bin rcu_eraseflash.bin] :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg/rcu_iconfflash.bin rcu_iconfflash.bin] :This FW version does not support scrubbing or Frame by Frame readback. :The flash with this firmware version on it shows "190606b" in the flash firmware version register. :This version is currently (13:32, 14 Mar 2008 (CET)) programmed on most of the RCUs of the TPC. We saw this version not working with few RCUs (5 of ~108), these RCUs have the original 190606 version programmed to their flash instead. :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg/rcu_fw_190606bg_bcmds.tar.gz rcu_fw_190606bg_bcmds.tar.gz package] ==== For the RCU firmware V1bg2 (FWV: 190606bg2):==== :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg2/rcu_eraseflash.bin rcu_eraseflash.bin] :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg2/rcu_iconfflash.bin rcu_iconfflash.bin] :This FW version does not support scrubbing or Frame by Frame readback. :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg2/rcu_fw_190606bg2_bcmds.tar.gz rcu_fw_190606bg2_bcmds.tar.gz package] ==== For the RCU firmware V1bg3 (FWV: 190606bg3):==== :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg3/rcu_eraseflash.bin rcu_eraseflash.bin] :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg3/rcu_iconfflash.bin rcu_iconfflash.bin] :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg3/rcu_scrubflash.bin rcu_scrubflash.bin] :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg3/rcu_framesflash.bin rcu_framesflash.bin] :This FW version does not support any data readout (<b><font color="red">!</font></b>) and should therefore only be used for test purposes. :*[http://web.ift.uib.no/~dominik/files/tools/rcu_fw_190606bg3/rcu_fw_190606bg3_bcmds.tar.gz rcu_fw_190606bg3_bcmds.tar.gz package] ==== For the RCU firmware V2==== :*still to come [[User:Dominik|Dominik]] 09:21, 31 Mar 2008 (CEST) f7dd09652140d819cdb02e83fcf8a6117006856a 12 62 140 2009-02-23T08:01:29Z Dfe002 7 New page: ==Most frequent wiki markup explained== <!--It is intended to be brief, or as an overview. Otherwise why we separate the materials into different pages? Thus it's best NOT to add new mater... wikitext text/x-wiki ==Most frequent wiki markup explained== <!--It is intended to be brief, or as an overview. Otherwise why we separate the materials into different pages? Thus it's best NOT to add new materials or expand here. Add more examples or expand in other areas like Wikitext examples. Thanks!--> Here are the most frequently used types of wiki markup. If you need more help see [[http://meta.wikimedia.org/wiki/Help:Editing]]. <br clear="right" /> {| class="wikitable" ! style="width: 50%" | What it looks like ! style="width: 50%" | What you type |- | You can ''italicize text'' by putting 2 apostrophes on each side. 3 apostrophes will embolden '''the text'''. 5 apostrophes will embolden and italicize '''''the text'''''. (4 apostrophes don't do anything special -- there's just ''''one left over''''.) |<pre> You can ''italicize text'' by putting 2 apostrophes on each side. 3 apostrophes will embolden '''the text'''. 5 apostrophes will embolden and italicize '''''the text'''''. (4 apostrophes don't do anything special -- there's just ''''one left over''''.) </pre> |- | You should "sign" your comments on talk pages: * Three tildes give your user name: [[User:Example|Example]] ([[User talk:Example|talk]])<br /> * Four tildes give your user name plus date/time: [[User:Example|Example]] ([[User talk:Example|talk]]) 07:46, 27 November 2005 (UTC) * Five tildes give the date/time alone: 07:46, 27 November 2005 (UTC) |<pre> You should "sign" your comments on talk pages: * Three tildes give your user name: ~~~ * Four tildes give your user name plus date/time: ~~~~ * Five tildes give the date/time alone: ~~~~~ </pre> |- | <div style="font-size:150%;border-bottom:1px solid rgb(170,170,170);">Section headings</div> ''Headings'' organize your writing into sections. The Wiki software can automatically generate a [[Help:Section|table of contents]] from them. <div style="font-size:132%;font-weight:bold;">Subsection</div> Using more equals signs creates a subsection. <div style="font-size:116%;font-weight:bold;">A smaller subsection</div> Don't skip levels, like from two to four equals signs. Start with 2 equals signs not 1 because 1 creates H1 tags which should be reserved for page title. |<pre> == Section headings == ''Headings'' organize your writing into sections. The Wiki software can automatically generate a table of contents from them. === Subsection === Using more equals signs creates a subsection. ==== A smaller subsection ==== Don't skip levels, like from two to four equals signs. Start with 2 equals signs not 1 because 1 creates H1 tags which should be reserved for page title. </pre> |- id="lists" | * ''Unordered [[Help:List|list]]s'' are easy to do: ** Start every line with a star. *** More stars indicate a deeper level. * Previous item continues. ** A new line * in a list marks the end of the list. *Of course you can start again. |<pre> * ''Unordered lists'' are easy to do: ** Start every line with a star. *** More stars indicate a deeper level. * Previous item continues. ** A new line * in a list marks the end of the list. * Of course you can start again. </pre> |- | # ''Numbered lists'' are: ## Very organized ## Easy to follow # Previous item continues A new line marks the end of the list. # New numbering starts with 1. |<pre> # ''Numbered lists'' are: ## Very organized ## Easy to follow # Previous item continues A new line marks the end of the list. # New numbering starts with 1. </pre> |- | : A colon (:) indents a line or paragraph. A newline starts a new paragraph. <br> Often used for discussion on [[talk pages]]. : We use 1 colon to indent once. :: We use 2 colons to indent twice. ::: 3 colons to indent 3 times, and so on. |<pre> : A colon (:) indents a line or paragraph. A newline starts a new paragraph. <br> Often used for discussion on talk pages. : We use 1 colon to indent once. :: We use 2 colons to indent twice. ::: 3 colons to indent 3 times, and so on. </pre> |- | Here's a link to the [[Main page]]. But be careful - capitalization counts! |<pre> Here's a link to the [[Main page]]. </pre> |- | [[Intentionally permanent red link]] is a page that doesn't exist yet. You could create it by clicking on the link. |<pre> [[Intentionally permanent red link]] is a page that doesn't exist yet. You could create it by clicking on the link. </pre> |- | You can link to a page section by placing a "#" before its title: * [[Help:Contents#For editors]]. If multiple sections have the same title, add a number. [[#Example section 3]] goes to the third section named "Example section". |<pre> You can link to a page section by its title: * [[Help:Contents#For editors]]. If multiple sections have the same title, add a number. [[#Example section 3]] goes to the third section named "Example section". </pre> |} 0d116a971a03d5c72ee80293718ecb48d9ffb1e7 6 63 141 2009-02-23T08:32:20Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 64 142 2009-02-23T08:32:52Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 65 143 2009-02-23T08:33:44Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 66 144 2009-02-23T08:34:16Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 67 145 2009-02-23T08:37:16Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 68 146 2009-02-23T08:37:45Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 69 147 2009-02-23T08:38:10Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2 70 148 2009-02-23T09:48:45Z Dfe002 7 New page: This is the personal page from Dominik Fehlker. wikitext text/x-wiki This is the personal page from Dominik Fehlker. 2b2f76b270f6ce2bca951bcd43c40da4c84894ba 2 71 149 2009-02-23T09:49:17Z Dfe002 7 New page: This is the personal page from Dag Toppe Larsen. wikitext text/x-wiki This is the personal page from Dag Toppe Larsen. 0eedac7417a9f7e5bb5ae9e6feecba893f7914ad 2 72 150 2009-02-23T09:49:55Z Dfe002 7 New page: This is the personal page from Kyrre Skjerdal. wikitext text/x-wiki This is the personal page from Kyrre Skjerdal. 24182d788e5ea76cf617c80e7108add8c0598945 2 73 151 2009-02-23T09:50:27Z Dfe002 7 New page: This is the personal page from Lars-Halvard Thunold Helleve. wikitext text/x-wiki This is the personal page from Lars-Halvard Thunold Helleve. 70761b4dd27338e40f460a60d13be6a49ba844eb 2 74 152 2009-02-23T09:56:37Z Dfe002 7 New page: This is the personal page from Johan Alme. wikitext text/x-wiki This is the personal page from Johan Alme. 5d0bf01c3f26c88be2e893080fa4ecf715556bff 2 75 153 2009-02-23T09:56:57Z Dfe002 7 New page: This is the personal page from Stian Scisly Sagevik. wikitext text/x-wiki This is the personal page from Stian Scisly Sagevik. afa727f16f22048e29b270362ebc911fb5a58fbd 2 76 154 2009-02-23T09:57:14Z Dfe002 7 New page: This is the personal page from Eli Renate Gruner. wikitext text/x-wiki This is the personal page from Eli Renate Gruner. 8d92a4ac060871bd137eb36afcc020af55dc24bc 2 77 155 2009-02-23T09:57:31Z Dfe002 7 New page: This is the personal page from Njål Brekke. wikitext text/x-wiki This is the personal page from Njål Brekke. fbcb3c682b55a6423ac13f26a9f83462819b6619 2 78 156 2009-02-23T09:57:50Z Dfe002 7 New page: This is the personal page from Ketil Røed. wikitext text/x-wiki This is the personal page from Ketil Røed. 337effb8e080d4dde145fbf214f11820c15a1bd8 2 79 157 2009-02-23T09:58:08Z Dfe002 7 New page: This is the personal page from Gaute Øvrebekk. wikitext text/x-wiki This is the personal page from Gaute Øvrebekk. d1c475a6401ff561c4fd6cfbb845f6ec83c77b99 2 80 158 2009-02-23T09:58:26Z Dfe002 7 New page: This is the personal page from Rikard Bølgen. wikitext text/x-wiki This is the personal page from Rikard Bølgen. 97bdb7372f9456e9e498c0b807a1be3fd5010512 2 81 159 2009-02-23T09:59:23Z Dfe002 7 New page: This is the personal page from Helge Opedal. wikitext text/x-wiki This is the personal page from Helge Opedal. 8897ed3bc28f5764d577a81466b060941848ccdf 2 82 160 2009-02-23T10:00:03Z Dfe002 7 New page: This is the personal page from Petter Kjelkenes. wikitext text/x-wiki This is the personal page from Petter Kjelkenes. 5ddf938c29227faedfdb43e7058e27bda7646909 0 3 161 2009-02-24T09:10:17Z Nfyku 4 wikitext text/x-wiki [[Category:Alice|Trigger]] == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Trigger]] 394dfab2be04580f650323ddfef8f1beb4778867 162 2009-02-24T09:12:32Z Nfyku 4 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 5c542922f8bf9ff163e5ab1228a0ed6d6bc4277b 0 22 163 2009-02-24T12:23:11Z St12361 17 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET senter at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == Characterisation Cell == [[Photomultipliers]] == Characterisation setup and results == [[Category:Detector lab]] 13571ebadf420eaa6b5d9138d459cb174b329ea0 179 2009-02-24T14:56:16Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |ZE |50 |74,2 |65 |65 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. == Characterisation Cell == == Characterisation setup and results == [[Photomultipliers]] [[Category:Detector lab]] 012eed33a97864ed0ba61956ff59adb08931fcd4 180 2009-02-25T07:24:19Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. == Characterisation Cell == == Characterisation setup and results == [[Photomultipliers]] [[Category:Detector lab]] 9b23a949837278241969113863eac4e1c2f70bda 181 2009-02-25T07:32:04Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. == Technology == === Avalanche Photodiodes === An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. == Characterisation Cell == == Characterisation setup and results == [[Photomultipliers]] [[Category:Detector lab]] 348bcf3fad0fc16a18bd76c460ec2e376367a61b 182 2009-02-25T07:41:37Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. == Technology == === Avalanche Photodiodes === An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. == Characterisation Cell == == Characterisation setup and results == [[Photomultipliers]] [[Category:Detector lab]] 1da881ea3f370f0a2eacff3a20ea7cb4e5eb0304 193 2009-02-25T07:54:24Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === [[Image:MAPD_radiotracer.JPG‎|frame|right|200px|Fluorodeoxyglucose-FDG]] [[Image:MAPD_positronelectronannihilation.JPG‎‎|frame|left|200px|Positron - Electron Annihilation]] The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === [[Image:MAPD_crystaltransition.JPG‎ |frame|left|200px|Electronic transition in a crystal]] A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. == Technology == === Avalanche Photodiodes === An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. == Characterisation Cell == == Characterisation setup and results == [[Photomultipliers]] [[Category:Detector lab]] eddf8acf01d0dbc097a598c58bdcc35d90ccb24d 196 2009-02-25T08:08:19Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === [[Image:MAPD_radiotracer.JPG‎|frame|right|200px|Fluorodeoxyglucose-FDG]] [[Image:MAPD_positronelectronannihilation.JPG‎‎|frame|left|200px|Positron - Electron Annihilation]] The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === [[Image:MAPD_crystaltransition.JPG‎ |frame|left|200px|Electronic transition in a crystal]] A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === [[Image:MAPD_coincidenceprinciple.JPG‎ |frame|none|200px|Coincidence detection principle]] In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. [[Image:MAPD_coincidencecategories.JPG|frame||200px|3 different coincidence detection events]] * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. [[Image:MAPD tofprinciple.jpg‎ |frame|none|200px|Time of flight principle]] [[Image:MAPD tofprinciple2.JPG|frame|none|200px|Time of flight principle]] == Technology == === Avalanche Photodiodes === [[Image:MAPD structure.jpg‎|frame|right|200px|Structure of MAPD]] An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. [[Image:MAPD proportionalmode.jpg‎ ‎|frame|right|200px|proportional mode]] * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. [[Image:MAPD geigermode.jpg‎‎|frame|right|200px|Geiger mode]] [[Image:MAPD_passivequenching.jpg‎‎|frame|right|200px|passive quenching]] The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. == Characterisation Cell == == Characterisation setup and results == == [[Photomultipliers]] == [[Category:Detector lab]] 30aff3cb6c53c8073313d5bd6ffbb54a3f8336d6 0 83 164 2009-02-24T12:55:12Z St12361 17 New page: <big>'''Photomultipliers'''</big> ===Critical Parameters=== {| border="1" cellpadding="5" cellspacing="0" |Parameter |Description |Typical Value (Fast PTM) |- |Rise Time (TR) |The time ... wikitext text/x-wiki <big>'''Photomultipliers'''</big> ===Critical Parameters=== {| border="1" cellpadding="5" cellspacing="0" |Parameter |Description |Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [[Image:[[Image:PMT_Parameters.jpg]]]] 4911071f322e3108f70dc90b8198c291877b15ff 165 2009-02-24T13:08:28Z St12361 17 wikitext text/x-wiki ===Critical Parameters=== {| border="1" cellpadding="5" cellspacing="0" |Parameter |Description |Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [[Image:[[Image:PMT_Parameters.jpg]]]] 840c51c75688b7378276828fa93aa2441ac1aac4 167 2009-02-24T13:10:28Z St12361 17 wikitext text/x-wiki ===Critical Parameters=== {| border="1" cellpadding="5" cellspacing="0" |Parameter |Description |Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [Image:PMT_Parameters.jpg] 7f7d950efad39a2fee910701544a449b47d36a61 168 2009-02-24T13:11:13Z St12361 17 wikitext text/x-wiki ===Critical Parameters=== {| border="1" cellpadding="5" cellspacing="0" |Parameter |Description |Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [[Image:Photomultiplier.jpg]] 594d4408589be38c8e9eb5a6c2c02b7446a9bbfe 169 2009-02-24T13:12:36Z St12361 17 wikitext text/x-wiki ===Critical Parameters=== {| border="1" cellpadding="5" cellspacing="0" |Parameter |Description |Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [[Image:PMT_Parameters.jpg]] 7f1e21e2e09b2f530738b063f8d548129149e603 170 2009-02-24T13:29:20Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="5" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) |- |R1161 |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |- |R5505 |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |} bd378e7b2188c5880c5797ba8ba353a0e7d8aebc 171 2009-02-24T13:43:07Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="2" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) !Pricing |- |R1161 |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |x |- |R5505 |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |x |- |R3478 |PMT - Head On |1700 V |1,7E+06 |300 to 650 |420 |6 nA |1,3 |14 |0,36 |x |- |7400U-02 |PMT - Head On |800 V |5,0E+05 |300 to 850 |500 |2 nA |0,78 |5,4 |0,23 |6404 SEK |- |7400-02 |PMT - Head On |800 V |7,0E+05 |300 to 850 |420 |0,2 nA |0,75 |5,4 |0,28 |6404 SEK |- |R380952 |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |2000/s |0,15 |0,55 |0,025 |126,346 SEK |- |R5916U-52 |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |0,5 |0,18 |1 |0,09 |148,643 SEK |} 41c4f3397382c37ac9a93775a6334dca5f5a640c 172 2009-02-24T13:45:15Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="2" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) !Pricing |- |R1161 |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |x |- |R5505 |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |x |- |R3478 |PMT - Head On |1700 V |1,7E+06 |300 to 650 |420 |6 nA |1,3 |14 |0,36 |x |- |7400U-02 |PMT - Head On |800 V |5,0E+05 |300 to 850 |500 |2 nA |0,78 |5,4 |0,23 |6404 SEK |- |7400-02 |PMT - Head On |800 V |7,0E+05 |300 to 850 |420 |0,2 nA |0,75 |5,4 |0,28 |6404 SEK |- |R380952 |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |2000/s |0,15 |0,55 |0,025 |126,346 SEK |- |R5916U-52 |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |0,5 |0,18 |1 |0,09 |148,643 SEK |} ===So whats's up with the MCP's?=== Microchannel Plate PMT, has plates containing numerous small holes, microchannels, which are lined with a secondary emissive dynode material. Electrons are amplified as they drop down the voltage gradients across the microchannel plate. MCP-PMT shows the fastes time response due to the restricted range of electron paths and short electron travel distance. Disadvantage is lower gain and photocurrent typ at 100 nA vs. 10-100uA for dyanode PMT [[Image:MCP-PMT.jpg]] 0980f7a19cba8fd84b41208b6253f8d54887a9b6 177 2009-02-24T14:19:03Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} <BR /> <BR /><BR /> [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="2" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) !Pricing |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r1166.php R1161] |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |x |- |R5505 |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |x |- |R3478 |PMT - Head On |1700 V |1,7E+06 |300 to 650 |420 |6 nA |1,3 |14 |0,36 |x |- |7400U-02 |PMT - Head On |800 V |5,0E+05 |300 to 850 |500 |2 nA |0,78 |5,4 |0,23 |6404 SEK |- |7400-02 |PMT - Head On |800 V |7,0E+05 |300 to 850 |420 |0,2 nA |0,75 |5,4 |0,28 |6404 SEK |- |R380952 |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |2000/s |0,15 |0,55 |0,025 |126,346 SEK |- |R5916U-52 |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |0,5 |0,18 |1 |0,09 |148,643 SEK |} ===So whats's up with the MCP's?=== Microchannel Plate PMT, has plates containing numerous small holes, microchannels, which are lined with a secondary emissive dynode material. Electrons are amplified as they drop down the voltage gradients across the microchannel plate. MCP-PMT shows the fastes time response due to the restricted range of electron paths and short electron travel distance. Disadvantage is lower gain and photocurrent typ at 100 nA vs. 10-100uA for dyanode PMT <BR /> [[Image:MCP-PMT.jpg]] 1c8d3d69754ce6e4bac393b4f74a01ab60d2e8db 178 2009-02-24T14:22:44Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} <BR /> [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="2" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) !Pricing |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r1166.php R1161] |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |x |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5509-42.php R5505] |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |x |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3478.php R3478] |PMT - Head On |1700 V |1,7E+06 |300 to 650 |420 |6 nA |1,3 |14 |0,36 |x |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u-02.php 7400U-02] |PMT - Head On |800 V |5,0E+05 |300 to 850 |500 |2 nA |0,78 |5,4 |0,23 |6404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u.php 7400-02] |PMT - Head On |800 V |7,0E+05 |300 to 850 |420 |0,2 nA |0,75 |5,4 |0,28 |6404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3809u-52.php R3809-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |2000/s |0,15 |0,55 |0,025 |126,346 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5916u-52.php R5916U-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |0,5 |0,18 |1 |0,09 |148,643 SEK |} ===So whats's up with the MCP's?=== Microchannel Plate PMT, has plates containing numerous small holes, microchannels, which are lined with a secondary emissive dynode material. Electrons are amplified as they drop down the voltage gradients across the microchannel plate. MCP-PMT shows the fastes time response due to the restricted range of electron paths and short electron travel distance. Disadvantage is lower gain and photocurrent typ at 100 nA vs. 10-100uA for dyanode PMT <BR /> [[Image:MCP-PMT.jpg]] ef75d780c6591af292b91fcde82a4c19f57c9f9d 6 84 166 2009-02-24T13:09:38Z St12361 17 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 85 173 2009-02-24T13:46:43Z St12361 17 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 3 86 174 2009-02-24T14:05:07Z Dfe002 7 New page: Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei ... wikitext text/x-wiki Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei 85de3bffc6039419fbe2f434fc02b84536094bb9 175 2009-02-24T14:05:17Z Dfe002 7 wikitext text/x-wiki Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei<br> Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei Hei e0d4320ce996bc4341d7f9b1b15a3bbfb062a370 176 2009-02-24T14:06:45Z Dfe002 7 Removing all content from page wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 87 183 2009-02-25T07:42:14Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 88 184 2009-02-25T07:42:22Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 89 185 2009-02-25T07:42:51Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 90 186 2009-02-25T07:43:06Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 91 187 2009-02-25T07:43:14Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 92 188 2009-02-25T07:43:22Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 93 189 2009-02-25T07:43:28Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 94 190 2009-02-25T07:43:34Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 95 191 2009-02-25T07:43:40Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 96 192 2009-02-25T07:43:48Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 34 194 2009-02-25T08:02:51Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med QuestaSim=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//QuestaSim) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs eller den innebygde teksteditoren i QuestaSim.Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter QuestaSim, og startes med kommandoen <pre> vsim & </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. Start et nytt prosjekt med <pre> File > New > Project </pre> Velg et fornuftig navn og katalog. Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i QuestaSim== Når koden kompilerer feilfritt kan den simuleres i QuestaSim. Dette startes med: <pre> vsim & </pre> QuestaSim bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i QuestaSim-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i QuestaSim, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> c7c9a87364f7b95f50b789a99451077cb707568e 200 2009-02-25T10:13:33Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa== Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando i et terminalvindu og start deretter et nytt skall. <pre> ssh -X mikroserver1 /prog/design_kits/micro.init.csh eller /prog/design_kits/micro.init.bash </pre> Senere skriver man følgende i et teminalvindu: <pre> ssh -X mikroserver1 mentor questa </pre> ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs eller den innebygde teksteditoren i Questa. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter Questa, og startes med kommandoen <pre> vsim & </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. Start et nytt prosjekt med <pre> File > New > Project </pre> Velg et fornuftig navn og katalog. Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim & </pre> Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] f68fe9d24a7bd8e0e7d7975f4f714781730ab826 201 2009-02-25T10:25:56Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa== Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando i et terminalvindu og start deretter et nytt skall. <pre> ssh -X mikroserver1 /prog/design_kits/micro.init.csh eller /prog/design_kits/micro.init.bash </pre> Senere skriver man følgende i et teminalvindu: <pre> ssh -X mikroserver1 mentor questa </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs eller den innebygde teksteditoren i Questa. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Simuleringsverktøyet for VHDL (og verilog) heter Questa, og startes med kommandoen <pre> vsim & </pre> Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim & </pre> Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] c99572cfd02c9b8b800f0403b91820c64f252dd3 6 97 195 2009-02-25T08:03:46Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 33 197 2009-02-25T10:07:14Z Nfyku 4 [[Modelsim]] moved to [[Modelsim/Questa]] wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] 02520b3a826446cadb898f5f72bc07059a5f2c49 0 98 198 2009-02-25T10:07:14Z Nfyku 4 [[Modelsim]] moved to [[Modelsim/Questa]] wikitext text/x-wiki #REDIRECT [[Modelsim/Questa]] 2bd37aece94713551ae800535452068c468bee84 0 25 199 2009-02-25T10:07:42Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphuics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System [[Category:Mikroelektronikk]] a3c78f627260f9df649a6882e78b0f672851c87a 6 99 202 2009-02-25T10:26:29Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 83 203 2009-02-25T14:17:59Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} <BR /> [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="2" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) !Pricing |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r1166.php R1161] |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |x |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5509-42.php R5505] |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |16 010 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3478.php R3478] |PMT - Head On |1700 V |1,7E+06 |300 to 650 |420 |6 nA |1,3 |14 |0,36 |3 837 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u-02.php 7400U-02] |PMT - Head On |800 V |5,0E+05 |300 to 850 |500 |2 nA |0,78 |5,4 |0,23 |6404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r2083.php R2083] |PMT - Head On |3000 V |2,5E+06 |300 to 650 |420 |100 nA |0,7 |16 |0,37 |14 955 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u.php 7400-02] |PMT - Head On |800 V |7,0E+05 |300 to 850 |420 |0,2 nA |0,75 |5,4 |0,28 |6404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3809u-52.php R3809-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |2000/s |0,15 |0,55 |0,025 |126,346 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5916u-52.php R5916U-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |0,5 |0,18 |1 |0,09 |148,643 SEK |} ===So whats's up with the MCP's?=== Microchannel Plate PMT, has plates containing numerous small holes, microchannels, which are lined with a secondary emissive dynode material. Electrons are amplified as they drop down the voltage gradients across the microchannel plate. MCP-PMT shows the fastes time response due to the restricted range of electron paths and short electron travel distance. Disadvantage is lower gain and photocurrent typ at 100 nA vs. 10-100uA for dyanode PMT <BR /> [[Image:MCP-PMT.jpg]] be77f7a27bf50f7210fd95b60d74368a09f223be 204 2009-02-25T14:19:08Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} <BR /> [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="2" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) !Pricing |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r1166.php R1161] |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |x |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5509-42.php R5505] |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |16 010 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3478.php R3478] |PMT - Head On |1700 V |1,7E+06 |300 to 650 |420 |6 nA |1,3 |14 |0,36 |3 837 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u-02.php 7400U-02] |PMT - Head On |800 V |5,0E+05 |300 to 850 |500 |2 nA |0,78 |5,4 |0,23 |6 404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r2083.php R2083] |PMT - Head On |3000 V |2,5E+06 |300 to 650 |420 |100 nA |0,7 |16 |0,37 |14 955 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u.php 7400-02] |PMT - Head On |800 V |7,0E+05 |300 to 850 |420 |0,2 nA |0,75 |5,4 |0,28 |6404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3809u-52.php R3809-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |2000/s |0,15 |0,55 |0,025 |126 346 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5916u-52.php R5916U-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |0,5 |0,18 |1 |0,09 |148 643 SEK |} ===So whats's up with the MCP's?=== Microchannel Plate PMT, has plates containing numerous small holes, microchannels, which are lined with a secondary emissive dynode material. Electrons are amplified as they drop down the voltage gradients across the microchannel plate. MCP-PMT shows the fastes time response due to the restricted range of electron paths and short electron travel distance. Disadvantage is lower gain and photocurrent typ at 100 nA vs. 10-100uA for dyanode PMT <BR /> [[Image:MCP-PMT.jpg]] 8c6b6064b679d689240cf754147b6e18edea221e 0 33 205 2009-02-26T12:12:53Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur [[Wikipedia:vhdl]] [[Category:Mikroelektronikk]] a5fdf292c26ccf1ac3f48ad49d3a44336c9bfc8b 206 2009-02-26T12:13:57Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[:Wikipedia:vhdl]] [[Category:Mikroelektronikk]] ee03082ca00823e04073096a6b56a4c4ed4896d2 207 2009-02-26T12:15:04Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/Vhdl|Wikipedia:vhdl]] [[Category:Mikroelektronikk]] 32753a0a8c2dadfae7036427db2127f68a77266f 208 2009-02-26T12:15:24Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/Vhdl Wikipedia:vhdl]] [[Category:Mikroelektronikk]] bfc9f26fb7bc6746f2533856d6111568f367633c 209 2009-02-26T12:16:13Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /pakke/mgc/altera/vhdl/apex20ke* [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDl]] [[Category:Mikroelektronikk]] 00cf2577abfac275ac8a08143848b2b66e58ab43 0 21 210 2009-02-27T10:56:02Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * Hege ... 0fd38c5880cb2b9c7c43d9bb5b89055a6d9b855b 225 2009-03-03T13:11:33Z St12361 17 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Lab Equipment == List of lab equipment, how to's and service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * Hege ... 1dd5dbc3dc087dfdc28b4937f617e91910dc6786 226 2009-03-03T13:12:33Z St12361 17 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * Hege ... ba7cfa92bcf88f59021e9447568b1a8cc3196ce9 0 100 211 2009-03-02T07:53:04Z Nfyku 4 New page: [[EDK tutorial 1]] Kom i gang med MicroBlaze og Xilinx Project Studio [[EDK tutorial 2]] Installere en generell buss IP for MicroBlaze til ekstern hardware (LCD skjerm) [[EDK tutorial 3]... wikitext text/x-wiki [[EDK tutorial 1]] Kom i gang med MicroBlaze og Xilinx Project Studio [[EDK tutorial 2]] Installere en generell buss IP for MicroBlaze til ekstern hardware (LCD skjerm) [[EDK tutorial 3]] VHDL design med ISE (implementering av enkel RS232 transmitter på virtex-4) [[Category:Mikroelektronikk]] f8acac995ceec9e552d5a6367cdd3d819d72eda2 0 101 212 2009-03-02T08:05:02Z Nfyku 4 New page: == Komme i gang med Xilix Projekt Studio 7.1i == En enkel men detaljert steg-for-steg veiledning til implementasjon av MicroBlase prosessoren på MEMEC protokort DS-BD-V4LX25MB. Dette er... wikitext text/x-wiki == Komme i gang med Xilix Projekt Studio 7.1i == En enkel men detaljert steg-for-steg veiledning til implementasjon av MicroBlase prosessoren på MEMEC protokort DS-BD-V4LX25MB. Dette er en kort veiledning for å komme i gang med et enkelt microblaze system. Dette oppsettet basere seg på et prototypekort fra MEMEC samt bruk av "base System Builder" filer. Du vil trenge XPS innstalert på maskinen samt tilgang til hyperterminal eller annen terminal som kan lese com-portene på PC'en din. == DEL 1 - Generere Prosjektfiler === === Installere MEMEC repository-files=== Før vi kan komme i gang med XPS, må vi sørge for at MEMEC's repository-filer er innstalert på maskinen. Filene kan lastes ned <a href="uploads/Memec_XBD_Files_EDK63h.zip">her</a> som en zip fil hvis de ikke allerede er innstalert på maskinen. Unzip filene legg dem i en katalog. Husk hvor du har plasert katalogen da du trenger å oppgi plaseringen senere. === Innstalere RS232-USB driver === Vi er også nødt til å ha installert USB-driveren hvis vi ønsker å kunne bruke RS232 til USB broen som er på MEMEC-kortet. Du finner driverene til chipen [[Media:cp2101.zip]] === Starte Xilinx Project Studio === Start programmet som heter "Xilinx Platform Studio". Når progammet har startet opp vil du få opp et vindu med spørsmål om lage et nytt prosjekt. Velg "Base System Builder Wizard" og klikk "OK". I neste vindu får en spøsmål om å lage en ny prosjekt fil. Skriv inn prosjektnavnet "TEST" og bruk browsefunksjonen til å velge en passende plass å legge prosjektfilene. Klikk så for å velge "User Peripheral Repository search patch for IP....", og bruk "browse" funksjonen til å finne katalogen hvor du innstalerte MEMEC repository files. Gå så videre med å klikke "ok". [[Image:EDK_XPS_01.jpg]] I neste vindu får du to valg. Merk "I would like to create a new design" og klikk "next". [[Image:EDK_XPS_02.jpg]] Her merker du "I would like to create a system for the following development board" og velger korekt prtotypekort fra menyen. Trykk så "next". [[Image:EDK_XPS_03.jpg]] I neste vindu velger du "MicroBlaze" og trykker "next". [[Image:EDK_XPS_04.jpg]] Du vil nå få opp et vindu hvor du kan sepsifisere MicroBlaze prosessorens egenskaper. Referanseklokken skal være 100MHz. Systemklokken kan settes til 100MHz(eller lavere hvis det skulle være ønskelig). Prosessorconfigurasjonen settes til "On-chip H/W debug module". Sett "Local data and instruction memory" til ønsket verdi, i vårt tilfelle 32kB. Velg "no cache". Klikk så "next". [[Image:EDK_XPS_05.jpg]] Du vil nå få opp et vindu hvor du kan velge I/O interface for prosessoren. Merk vekk "Ethernet MAC" og sett hastigheten på "RS232_USB" opp til maks (921600). Trykk så "next". [[Image:EDK_XPS_06.jpg]] I dette vinduet lar du alt stå som det er og trykker "next". [[Image:EDK_XPS_07.jpg]] Her settes minneområdene. La alt sto som det er og trykk "next". [[Image:EDK_XPS_08.jpg]] I neste vindu får du spørsmål om å legge til enheter. Ikke gjør noe men trykk "next". Du vil nå få opp et vindu med spørsmål om hva som skal være standar IO enhet. trykk også på valg for "Memory Test". Velg RS232 og trykk "next2. [[Image:EDK_XPS_09.jpg]] I vinduet som nå kommer opp kan du velge hvor du vil plasere intruksjon, data og stack minne. La de valgte verdier stå og trykk "next". [[Image:EDK_XPS_10.jpg]] Du vil nå få opp en oversikt over prosessoren og adresser til de forskjellige enhetene koblet til den. Trykk "Generate" og du vil få generert et prosjekt basert på dine valg. [[Image:EDK_XPS_11.jpg]] Du får så opp et vindu som sier at prosjektet er generert. Trykk "Finish". Du vil nå se at prosjektet blir lastet inn i XPS. Du får også et lite vindu som heter "the next step". Velg "start using platform studio" og trykk "ok". [[Image:EDK_XPS_12.jpg]] == DEL 2 - Kjøre en testaplikasjon == Du har nå fått et komplett MicroBlaze system i ditt prosjekt. Det neste steget blir å kjøre en testaplikasjon som ligger i prosjektet ditt og på denne måten få bekreftet at prosessoren kjører som den skal. === Synthesisere prosjektet === For å få generert en prosjektfil som kan lastes ned på FPGA'en må en gå på tools menyen og trykke "Generate Bitstream". XPS vil nå jobbe i en til to timer. [[Image:EDK_XPS_16.jpg]] Når bitmap filen er ferdig vil du få følgende beskjed i outputvinduet: <pre> Analyzing file TestApp_Memory/executable.elf... INFO:MDT - BRAM lmb_bram will be initialized with ELF of processor microblaze_0 Running Data2Mem with the following command: data2mem -bm implementation/system_bd -bt implementation/system.bit -bd TestApp_Memory/executable.elf tag lmb_bram -o b implementation/download.bit Memory Initialization completed successfully. Done. </pre> === Enable XMD debug === Gå på "optionsmenyen" og velg "XMD debug Options". I vinduet som kommer opp merker du av "hardware" og trykker "save". [[Image:EDK_XPS_19.jpg]] === Kompilere programkoden === Til venstre i XPS åpner en vinduet som heter "Application". Høyreklikk på "xmdstud" og pass på at "mark to initialize BRAMs" er er umarkert. Gjør det samme med "Project: TestApp_Memory" og sørg for at "mark to initialize BRAMs" er markert. === Legg til opsjoner === I prosjektlista dobbelklikker du på source og åpner filen som ligger der. Du vil da få åpnet kildekoden din i hovedvinduet. [[Image:EDK_XPS_14.jpg]] Bla deg ned i TestApp_Memory.c filen og finn main rutinen. Her legger du til "<em>print("Dette er en test av 'ditt navn'\n\r"); </em>". <pre> //==================================================== int main (void) { print("-- Entering main() --\r\n"); print("Dette er en test av 'ditt navn'\n\r"); /* * MemoryTest routine will not be run for the memory at * 0x00000000 (dlmb_cntlr) * because it is being used to hold a part of this application program */ </pre> Trykk på lagre og åpne deretter menyen "tools" og velg "Build All User Aplication". All programkode vil da bli kompilert og du vil få en utskrift som forteller størrelse på progamkoden. [[Image:EDK_XPS_13.jpg]] <pre> mb-size TestApp_Memory/executable.elf text data bss dec hex filename 3968 300 8 4276 10b4 TestApp_Memory/executable.elf Done. </pre> === Laste over bitfilen til virtex-4 === Koble til parallellport-programereren fra xilinx til kortet og koble til en seriellkabel mellom kortet og PC'en. Start opp hyperterminal eller et alternativt program. Velg com1. I neste vindu setter du baudraten til 9600, databits til 8, velger "none" på parity, setter stopbit til 1 og velger hardware på "flow control". Trykk så på "apply". [[Image:EDK_XPS_17.jpg]] === Overføre sowftwaren til MicroBlaze prosessoren === Neste steg er nå å laste over prosessoren på FPGA'en. Slå på strømmen på prototypekortet. Velg så tools menyen og trykk på "Download". Når nedlastingen er ferdig vil du få opp følgende tekst i outputvinduet: <pre> INFO:iMPACT:579 - '1': Completed downloading bit file to device. INFO:iMPACT:580 - '1':Checking done pin ....done. '1': Programmed successfully. Elapsed time = 3 sec. // === BATCH CMD : quit Done. </pre> Du vil nå starte kjøringen av programet straks nedlastingen er fredig. I hyperterminal vil du få opp en tekst som sier: <pre> -- Entering main() -- Dette er en test av 'ditt navn' Starting MemoryTest for DDR_SDRAM_32Mx16: Running 32-bit test...PASSED! Running 16-bit test...PASSED! Running 8-bit test...PASSED! -- Exiting main() -- </pre> Gratulerer!!! Du har nå implementert et enkelt softcore prosessorsystem på FPGA'en. [[Category:Mikroelektronikk]] e374eec5a71dc56eee0812275d8336a8e9990bf5 0 102 213 2009-03-02T08:12:18Z Nfyku 4 New page: == Installering av en generell IP og tilhørende softwaredriver for MicroBlaze i Xilix Projekt Studio 7.1i == En enkel steg-for-steg veiledning til implementasjon av en softwaredriver for... wikitext text/x-wiki == Installering av en generell IP og tilhørende softwaredriver for MicroBlaze i Xilix Projekt Studio 7.1i == En enkel steg-for-steg veiledning til implementasjon av en softwaredriver for LCD på MEMEC protokort DS-BD-V4LX25MB Dette er en kort veiledning lage software-drivere til eksterne komponenter i et microblaze system. Dette oppsettet basere seg på et prototypekort fra MEMEC. Vi vil ta utgangspunkt i det lille 2x16 tegns LCD-skjermen som følger med på kortet. Har du kjørt tutorial 1 vil du legge merke til at LCD displayet ikke ble inkludert i prosjektet. Dette må dermed legges til manuelt i ettertid. Siden det er snakk om en enkel IO enhet kan vi bruke en generell buss-IP uten å tenke på ekstra VHDL-kode som må implementeres. Du vil trenge XPS innstalert på maskinen samt tilgang til hyperterminal eller annen terminal som kan lese com-portene på PC'en din. == DEL 1 - Legge til IP== === Lage IP === Åpne prosjektet fra tutorial 1 i XPS. Åpne menyen "project" og velg "Add/Edit Cores... (dialog)". [[Image:EDK_XPS_20.jpg]] Du vil nå få opp en oversikt over alle enheter som er tilkoblet prosessoren. I listen over tilgjenglige IP'er, velg "opb_gpio" og trykk "add". Du vil nå legge til en ny ip. Gi Ip'en navnet "LCD_module" og klikk "apply". [[Image:EDK_XPS_21.jpg]] I samme vindu velger du så menyen "Bus Connections". Bla deg ned på listen her til du finner "LCD_module sopb". Marker enhenten som slave for mb_opb bussen. Klikk så på "apply". [[Image:EDK_XPS_22.jpg]] Gå videre til "Adresses". Her trykker du på knappen "Generate Addresses". XPS vil da automatisk generere en adresse til IP'en vår. Du vil få opp et vindu som spør om du vil fortsette. klikk "Yes". Ip'em din vil nå ligge i adresseområdet 0x40040000-0x4004ffff, har du fått en annen verdi så husk denne verdien da du må bruke denn og ikke 0x40040000 videre i tutorialen. Trykk så "apply". [[Image:EDK_XPS_23.jpg]] Gå nå til menyen "Ports". Her skal vi koble interne signaler fra IP'en til et signal som senere kan rutes til pinner på FPGA'en. Begynn med å velge "LCD_module" i "Ports Filter". Bøa deg så ned i "List of Ports" til du finner signalene til vår IP. Hold nede "ctrl" tasten og velg "OPB_CLK" samt "GPIO_d_out". Trykk så "Add" for å legge dem til "Internal Ports Connection". For signalet OPB_CLK forandrer du "Net name" til "sys_clk_s". For signalet "GPIO_d_out" forandrer du "Net name" til fpga_lcd_module". I listen over "External Ports Connection" trykker du "Add Port". Du får nå opp et lite vindu som du må fylle ut data i. I linjen for "Port Name" skriver du "fpga_lcd_module". Sett "Port Polaritet" til "OUT" og gi "connected to" navnet "fpga_lcd_module". Trykk "Ok". Du må nå legge til "Range" for den eksterne porten vi definerte. Skriv inn "[0:9]". Trykk "Apply". [[Image:EDK_XPS_24.jpg]] Velg så menyen "Parameters". I rullegardinlisten over IP'er velger du LCD_module. Marker parametrene; "C_GPIO_WIDTH", "C_IS_DUAL", "C_ALL_INPUTS" og "C_IS_BIDIR". Trykk "Add". Sett så verdien til 10 for "C_GPIO_WIDTH" og til 0 for de tre andre. Trykk "Apply" og "Ok". [[Image:EDK_XPS_25.jpg]] Du har nå lagt til en IP som er koblet til OPB bussen og har 10 signallinjer(utganger) som kan kobles til fpga'ens pinner. Siden det her er snakk om en Ip som allerede eksisterer slipper vi å lage egene softwaredrivere til IP'en. === Koble til eksterne pinner === Neste steg er nå å rute våre 10 signal til rette pinner på fpga'en. Det gjøres i "user constraint" filen. Denne finner en under "Project files" og den heter "system.ucf". Åpne denne filen. [[Image:EDK_XPS_26.jpg]] Her legger vil til signalene våre og hvilke pinner de skal bruke samt hvilke type signal det er snakk om: <pre> ############################################################################ ## This system.ucf file is generated by Base System Builder based on the ## settings in the selected Xilinx Board Definition file. Please add other ## user constraints to this file based on customer design specifications. ############################################################################ Net sys_clk_pin LOC=B13 | IOSTANDARD = LVCMOS25; Net sys_rst_pin LOC=AB9; Net sys_rst_pin PULLUP | IOSTANDARD = LVCMOS25; ## System level constraints Net sys_clk_pin PERIOD = 10000 ps; Net sys_rst_pin TIG; ## FPGA pin constraints ## Legg til våre signaler her ## lcd_enable (9) Net fpga_lcd_module<0> LOC = AD10 | IOSTANDARD = LVCMOS25; ## lcd_RS (8) Net fpga_lcd_module<1> LOC = AC11 | IOSTANDARD = LVCMOS25; ## lcd_data( 7-0 ) Net fpga_lcd_module<2> LOC = Y6 | IOSTANDARD = LVCMOS25; Net fpga_lcd_module<3> LOC = W7 | IOSTANDARD = LVCMOS25; Net fpga_lcd_module<4> LOC = AD6 | IOSTANDARD = LVCMOS25; Net fpga_lcd_module<5> LOC = AE6 | IOSTANDARD = LVCMOS25; Net fpga_lcd_module<6> LOC = AC7 | IOSTANDARD = LVCMOS25; Net fpga_lcd_module<7> LOC = AD8 | IOSTANDARD = LVCMOS25; Net fpga_lcd_module<8> LOC = AC8 | IOSTANDARD = LVCMOS25; Net fpga_lcd_module<9> LOC = AC9 | IOSTANDARD = LVCMOS25; Net fpga_0_RS232_RX_pin LOC=B14 | IOSTANDARD = LVCMOS25; Net fpga_0_RS232_TX_pin LOC=T7 | IOSTANDARD = LVCMOS33; Net fpga_0_RS232_req_to_send_pin LOC=T8 | IOSTANDARD = LVCMOS33; </pre> Lagre filen når du er ferdig. Gå på "tools" menyen og velg "Update bitstream". XPS vil nå lage nye bitfiler med driveren inkludert. Dette tar gjene 1 til 2 timer. Bruk denne tiden til å ta deg en kaffe og gratulere deg selv over at du nå er klar til neste steg. == DEL 2 - Lage program til LCD == === Includefil for lcd-skjerm === For å kunne teste ut lcd-skjermen og IP'en vi har laget til den trenger vi et lite bibliotek med funkjsoner som lar oss skrive på skjermen. Nedenfor er det listet opp enn c fil som inneholder disse rutinene, samt en header fil. Disse filene, <a href="uploads/lcd.c">lcd.c</a> og <a href="uploads/lcd.h">lcd.h</a>, må legges inn i prosjektkatalogen din på følgende sted: "...test/TestApp_Memory/src" <pre> //------------------------------------- //-- Masteroppgave 2005 -- //-- av -- //-- Tor Aleksander Birk Danielsen -- //-- -- //-- Driverfunkjsoner for 2x16 -- //-- lcd display -- //------------------------------------- // // LCD_module_address må defineres #include "xgpio_l.h" #include "xutil.h" #define LCD_module_address 0x40040000 #define lcd_type 2 // 0=5x7, 1=5x10, 2=2 lines #define lcd_line_two 0x40 // LCD RAM address for the second line //======================================= //== liten delayfunkjson brukt i lcd.c == //======================================= void delay_ms(int delay_m){ volatile int delay=0; volatile int i=0; for (i=0; i<= delay_m; i++){ for (delay=0; delay<9000; delay++){ //delay } } } //================================ //== sender byte til lcd skjerm == //================================ void lcd_send_byte(int address, Xuint32 data){ if (address != 0) data = data | 0x100; else data = data & 0xFF; XGpio_mSetDataReg(LCD_module_address, 1, data); data = data | 0x200; delay_ms(2); XGpio_mSetDataReg(LCD_module_address, 1, data); delay_ms(5); data = data & 0x1FF; XGpio_mSetDataReg(LCD_module_address, 1, data); } //=================================* //== gå til punkt på lcd skjermen == //=================================* void lcd_gotoxy(int x,int y) { int address; if(y!=1) address=lcd_line_two; else address=0; address+=x-1; lcd_send_byte(0,0x80|address); } //========================* //== skriver tegn på lcd == //========================* void lcd_putc( char c) { switch (c) { case '\f' : lcd_send_byte(0,1); delay_ms(2); break; case '\n' : lcd_gotoxy(1,2); break; case '\b' : lcd_send_byte(0,0x10); break; default : lcd_send_byte(1,c); break; } } //================================ //== initialiserer LCD skjermen == //================================ void lcd_init(void){ int i; Xuint32 init[4]; init[0] = 0x00f; //init display init[1] = 0x001; //clear display init[2] = 0x038; //enable 8 bit data XGpio_mSetDataDirection(LCD_module_address, 1, 0x00000000); delay_ms(100); for(i=0; i<=2; i++){ XGpio_mSetDataReg(LCD_module_address, 1, init[i]); init[i] = init[i] | 0x200; //enable høy delay_ms(2); XGpio_mSetDataReg(LCD_module_address, 1, init[i]); delay_ms(100); init[i] = init[i] & 0x1FF; //enable lav XGpio_mSetDataReg(LCD_module_address, 1, init[i]); delay_ms(100); } } //=======================================* //== Skriver strenger til LCD displayet == //=======================================* void lcd_string(char *s){ while (*s) { lcd_putc(*s); s++; } return; } //=============================================== //== Skriver ut en testmelding på lcd skjermen == //=============================================== void lcd_test_msg(void){ lcd_putc('\f'); lcd_gotoxy(1,1); lcd_string("* Test av LCD *"); lcd_gotoxy(1,2); lcd_string("*abcdefghijklmn*"); } </pre> <pre> //===================================== //== Masteroppgave 2005 == //== av == //== Tor Aleksander Birk Danielsen == //===================================== //-- -- //-- Filnavn: lcd.h -- //-- Dato: 06/06-2005 -- //-- -- //------------------------------------- #include "xgpio_l.h" #include "xutil.h" //------------------------------------- // delay_ms(millisekund); //------------------------------------- // enkel funksjon som generer delay i ms området void delay_ms(int delay_m); //------------------------------------- // lcd_string(); //------------------------------------- // Skriver ut en streng på lcd-skjermen void lcd_string(char *s); //------------------------------------- // lcd_init(); //------------------------------------- // initialiserer et 2x16 lcd display void lcd_init(void); //------------------------------------- // lcd_send_byte(address,data); //------------------------------------- // Sender en byte til lcd displayet // Første variabel er '0' hvis det // registerinfo som sendes, ellers // er den '1' for tegn void lcd_send_byte(int address, Xuint32 data); //------------------------------------- // lcd_send_nibble(data,address); //------------------------------------- //??? ikke i bruk void lcd_send_nibble(int data, int address); //------------------------------------- // lcd_gotoxy(x,y); //------------------------------------- // Gå til et punkt på lcd skjermen void lcd_gotoxy(int x,int y); //------------------------------------- // lcd_putc(c); //------------------------------------- // skriver ut en bokstav på lcd skjerm // spesialtegn: // '\f' // '\n' // '\b' void lcd_putc( char c); //------------------------------------- // lcd_test_msg(); //------------------------------------- // skriver ut en testmelding void lcd_test_msg(void); </pre> === Main fil === Du vil også trenge en main rutine som kjører hovedprogrammet ditt. Denne filen <a href="uploads/main.c">main.c</a> må du også legge inn i samme prosjektkatalog, "...test/TestApp_Memory/src", som de to forrige filene. <pre> //----------------------------------- //-- toturial 2 -- //-- test av lcd-skjerm -- //-- -- //-- Tor Aleksander Birk Danielsen -- //----------------------------------- //-- include headers -- #include "xparameters.h" #include "xgpio_l.h" #include <stdio.h> #include "lcd.h" int main(void) { print("--main_rutine--\n\r"); print("lcd init...."); lcd_init(); //inintialiserer lcd skjerm print("ok\n\r"); print("skriver test msg på lcd\n\r"); lcd_test_msg(); delay_ms(2000); // 2sek delay print("skiver streng på lcd\n\r"); lcd_putc('\f'); //ny skjerm lcd_gotoxy(1,1); //setter markør i øvre venstre hjørne lcd_string("dette virker jo!"); //skriver ut en streng while(1); //stopper programmet her med evig sløyfe } </pre> Du må nå åpne "applications" menyen og åpne prosjektet "TestApp_Memory". Høyreklikk på filen "TestApp_Memory.c" og slett den. Høyreklikk på "source" og velg "add file..". Legg til "lcd.c" og "main.c". Velg "header" og legg til på samme måte "lcd.h". [[Image:EDK_XPS_27.jpg]] Pass på at "#define LCD_module_address 0x40040000" i lcd.c peker til rett adresse. Denne adressen ble automatisk generert tidligere i oppgaven og skal ideelt sett være lik. Gå på "tools" menyen og velg "Build All User Aplications". Du vil nå få kompilert c-koden din. Start så opp hyperterminal med samme innstilinger som forrige gang. Gå på "tools" menyen og velg "downloads". Du vil nå få lastet over prosessor og programkode på fpga'en. På lcd skjermen vil du få opp følgende to meldinger med 2 sek mellomrom: <pre> * Test av LCD * *abcdefghijklmn* </pre> <pre> dette virker jo! </pre> og på hyperterminal vil følgende melding komme opp: <pre> --main_rutine-- lcd init....ok skriver test msg på lcd skiver streng på lcd </pre> [[Category:Mikroelektronikk]] dcb0fc3e8b4d6bbe502f5a121e0c49eb5910932f 0 103 214 2009-03-02T08:19:40Z Nfyku 4 New page: == VHDL design i ISE 7.1 for virtex-4 == En enkel steg-for-steg veiledning til implementasjon av en RS232 transmitter på en virtex-4 FPGA Dette er en kort introduksjon til Xilinx ISE og... wikitext text/x-wiki == VHDL design i ISE 7.1 for virtex-4 == En enkel steg-for-steg veiledning til implementasjon av en RS232 transmitter på en virtex-4 FPGA Dette er en kort introduksjon til Xilinx ISE og vhdl design i EDK. Vi tar utgangspunkt i det samme prototypekortet (DS-BD-V4LX25MB) som i turtorail 1 og 2. Målet er å lage en enkelt RS232 transmitter som sender koden på DIP-bryterene til en terminal på PC'en. Du vil trenge hyperterminal eller et annet tilsvarende program til å lese COM porten på PC'en. === Lage nytt prosjekt === Start programmet "Project Navigator" under "Xilinx ISE 7.1i" menyen. Når du starter opp vil forrige prosjekt automatisk ligge der hvist noen har brukt ISE før deg. I tilfelle så lukker du prosjektet ved å velge "Close Project" under "File" menyen. Fra "file" menyen velger du så "New Project". Du vil nå få opp et vindu hvor du kan navngi prosjektet og velge plasering. Kall prosjektet "RS232" og finn en passende plasering for prosjektkatalogen. "Top Level Module Type" setter du til VHD. Trykk så "Next" [[Image:EDK_XPS_30.jpg]] Du vil nå få opp et vindu hvor du kan velge hviken FPGA du vil bruke, samt vertøyvalg. Sett "Device Family" til Virtex4, "Device" til "xc4vlx25", "Package" til "ff668" og "Speed Grade til -10". "Synthesis Tool" settes til "XST", "Simulator" til "ISE simulator" og simuleringsspråk settes til VHDL. Trykk så "Next". [[Image:EDK_XPS_31.jpg]] Du vil nå få opp ett vindu hvor du har muligheten til å få generert en kildefil til prosjektet. Trykk på "New Source". [[Image:EDK_XPS_32.jpg]] Velg "VHDL Module" og gi den navnet "RS232_main". Pass på at boksen "Add to Project" er merket og trykk "Next". [[Image:EDK_XPS_33.jpg]] Du kan nå legge til porter. Legg inn portene; clk, reset og send som "in". Legg til data som "in" og sett MSB til 7 og LSB til 0. Legg til port tx og opptatt som "out". Trykk så "Next". [[Image:EDK_XPS_34.jpg]] Du får nå opp et vindu med et samendrag av kildefilen din. Trykk "Finish". Du kommer nå tilbake til vinduet hvor du kan legge til kildefiler. Trykk "Next". Neste vindu lar deg legge til ferdige kilderfiler. Ta filene [[Media:rs232_clk.vhd">rs232_clk.vhd</a> og [[Media:rs232_tx.vhd">rs232_tx.vhd</a> og last dem ned på maskinen din. <pre> --------------------------------- --Tor Aleksander Birk Danielsen-- -- klokke til RS232 -- -- 10.04.2005 -- --------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity rs232_clk is port( clk : in std_logic; --main clk 100MHz reset : in std_logic; --global reset clk_tx : inout std_logic; --sendeklokke 16*baudrate bit_send : out std_logic); --pulstog 1*baudrate end rs232_clk; architecture Behavioral of rs232_clk is --interne tellere signal clk_teller_1 : std_logic_vector(0 to 8); signal clk_teller_2 : std_logic_vector(0 to 3); begin --------------------------------------- --lage klokkefrekvens på 16xbaudraten-- -- clk/(budrate*16) = tellerverdi*2-- -- 100MHz/(9600*32) = 325 = 101000101-- --------------------------------------- process (clk) begin if clk'event and clk='1' then if reset = '1' then clk_teller_1 <= clk_teller_1 + 1; if clk_teller_1 = "101000101" then clk_tx <= not clk_tx; clk_teller_1 <= "000000000"; end if; else clk_teller_1 <= "000000000"; end if; end if; end process; --------------------------------------- --lage 1/16 puls av clk_tx til sender-- -- dvs pulstog med samme frekvens -- -- som baudraten -- --------------------------------------- process (reset, clk_tx) begin if reset = '0' then bit_send <= '0'; clk_teller_2 <= "0000"; elsif rising_edge(clk_tx) then clk_teller_2 <= clk_teller_2 + 1; if clk_teller_2 = "1111" then bit_send <= '1'; elsif clk_teller_2 = "0000" then bit_send <= '0'; end if; end if; end process; end Behavioral; </pre> <pre> --------------------------------- --Tor Aleksander Birk Danielsen-- -- sender RS232 -- -- 10.04.2005 -- --------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity rs232_tx is port( clk_tx : in std_logic; --clk 16 * baudrateklokke reset : in std_logic; --global reset bit_send : in std_logic; --pulstog 1*baudrate send : in std_logic; --starter transmitt data : in std_logic_vector(7 downto 0); --data som skal sendes tx : out std_logic; --transmittpinne opptatt : out std_logic); --sender opptatt signal end rs232_tx; architecture Behavioral of rs232_tx is type tilstander is (idle, start_sending, sender, stop_send); signal sende_data : tilstander := idle; signal transmitt_buffer : std_logic_vector(9 downto 0); --transmitt buffer (10 bit) signal transmitt_data : std_logic_vector(7 downto 0); --inneholder databyte som skal sendes signal bit_teller: integer := 9; begin ------------------------- --senderutine for rs232-- ------------------------- sender_rs232: process (reset, clk_tx) begin if reset='0' then opptatt <= '0'; sende_data <= idle; transmitt_buffer <= (others=> '1'); elsif rising_edge(clk_tx) then case sende_data is when idle => if send = '0' then transmitt_data <= data; opptatt <= '1'; sende_data <= start_sending; else opptatt <= '0'; end if; when start_sending => if bit_send = '1' then sende_data <= sender; bit_teller <= 9; transmitt_buffer <= '1' & transmitt_data & '0'; end if; when sender => if bit_send = '1' then bit_teller <= bit_teller - 1; transmitt_buffer <= '1' & transmitt_buffer(transmitt_buffer'high downto 1); if bit_teller = 1 then sende_data <= stop_send; end if; end if; when stop_send => if bit_send = '1' then sende_data <= idle; end if; When others => sende_data <= idle; end case; end if; end process; tx <= transmitt_buffer(0); end Behavioral; </pre> Trykk så "Add Source" og legg begge filene til prosjektet. På spørsmål om filtype velg "VHDL design file". Trykk så "Next". [[Image:EDK_XPS_35.jpg]] Du vil nå få opp et sammendrag av prosjektet ditt. Trykk "Finish" og prosjektet vil bli generert. === Lage koden === Vi har nå en main fil samt en fil med klokkekode og en fil med transisjonskode. Neste steg bli å inkludere klokken og senderen i hovedfilene vår. Dobbeltklikk på filen "RS232_main.vhd" under "Module View" for å åpne filen for editering. Legg til følgende kodebit mellom "architecture .." og "begin": <pre> --legger til komponenter component rs232_clk port ( clk : in std_logic; reset : in std_logic; clk_tx : out std_logic; bit_send : out std_logic); end component; component rs232_tx port ( clk_tx : in std_logic; reset : in std_logic; bit_send : in std_logic; send : in std_logic; data : in std_logic_vector(7 downto 0); tx : out std_logic; opptatt : out std_logic); end component; --definere interne signaler signal bit_send : std_logic; signal clk_tx : std_logic; </pre> Etter begin legges følgende kodebit inn: <pre> -- kobler klokke og tx signaler til rs232_main entity sig. klokke_gen: rs232_clk port map( clk, reset, clk_tx, bit_send); transmitt: rs232_tx port map( clk_tx, reset, bit_send, send, data, tx, opptatt); </pre> Filen [[Media:RS232_main.vhd]] kan lastes ned ferdig hvis du er usikker på om du har lagt inn koden korrekt. Når du er ferdig med å redigere main filen tar du å lagrer prosjektet. Neste steg blir å test om koden er korekt. I "prosess View" vinduet går du til "Design Utilities" og dobbelklikker på "Check Syntax for Simulation". Har du gjort alt korekt skal du ikke få noen feilmelding nå. I "Module view" kan du også se at RS232_clk og RS232_tx har blitt underordnet RS232_main. === Legge til pinner === Neste steg er å legge til "user constraints" som i vårt tilfelle betyr å definere hvilke pinner som skal til hviken port. I "Module View" menyen markerer du filen RS232_main.vhd da det er denne filen du ønsker å legge "User Constraints" til. Når filen er markert går du til "Prosess View" vinduet og velger "User Constraints" menyen. Dobbeltklikk på "Assign Package Pins". Du vil nå få spørsmål om du vil legge til en UCF fil til prosjektet. Trykk "Yes". Du får nå opp et nytt vindu. I "Design Object List" vinduet har du en oversikt over alle IO porter i prosjektet ditt. Vi skal nå legge inn pinnr i "Loc" til hver av portene. Legg til følgene: [[Image:EDK_XPS_36.jpg]] Når du er ferdig lagrer du og avslutter hele 2Xilinx Pace" vinduet. Du har nå fått generert en UCF fil til prosjektet ditt som inneholder følgende: <pre> #PACE: Start of Constraints generated by PACE #PACE: Start of PACE I/O Pin Assignments NET "clk" LOC = "B13" ; NET "data<0>" LOC = "AD11" ; NET "data<1>" LOC = "AC12" ; NET "data<2>" LOC = "AC13" ; NET "data<3>" LOC = "AD13" ; NET "data<4>" LOC = "AC14" ; NET "data<5>" LOC = "AD14" ; NET "data<6>" LOC = "AC15" ; NET "data<7>" LOC = "AB7" ; NET "opptatt" LOC = "AE9" ; NET "reset" LOC = "AB9" ; NET "send" LOC = "AA11" ; NET "tx" LOC = "T7" ; #PACE: Start of PACE Area Constraints #PACE: Start of PACE Prohibit Constraints #PACE: End of Constraints generated by PACE </pre> === Sythesisering og Implementering === Neste steg blir å Synthesiserer og implementere deisgnet vårt. Marker igjen filen RS232_main.vhd i "Module View" vinduet og dobbeltklikk på "Genreate Programming File" i "Process View". Du vil nå få generert en bit fil som kan lastes over i FPGA'en. === Programering og testing === Vi skal nå programmere FPGA'en. Sørg for at det er strøm på kortet og at programmeringsadapterert er koblet til. Start også hyperterminal med med en baudrate på 9600kbps. Gå til "Process View" og dobeltklikk på "Configure Device(iMPACT). Du åpner nå iMPACT programmet. På spørsmålom konfigurerig velg "Boundary-Scan mode". I neste vindu velger du automatisk tilkobling. Trykk så "Finish". iMPACT vil nå automatisk sjekke hvor mange og hvilke type FPGA'er som er koblet til programmeringsadapterert. Du vil få et vindu som sier at en enhet er funnet. Trykk "Ok". Du får nå opp et vindu der du blir bedt om å tilordne en new configureringsfil. Velg filen rs232_main.bit. Du får nå opp en advarsel. Ignorer denne og trykk "Ok". Høyreklikk på bildet av Virtex4 og velg "porgram...". Trykk så "Ok". Du vil nå programere FPGA'en. [[Image:EDK_XPS_37.jpg]] Hvis du nå trykker "Push2" bryteren vil du få bittmønsteret til DIP-bryterene oversendt til hyperterminal som ASCII kode. Du har nå suksessfult laget og implementert VHDL kode med ISE. [[Category:Mikroelektronikk]] f3ed7b8daea31380399025ed0246f1a294a78ac7 215 2009-03-02T08:20:31Z Nfyku 4 wikitext text/x-wiki == VHDL design i ISE 7.1 for virtex-4 == En enkel steg-for-steg veiledning til implementasjon av en RS232 transmitter på en virtex-4 FPGA Dette er en kort introduksjon til Xilinx ISE og vhdl design i EDK. Vi tar utgangspunkt i det samme prototypekortet (DS-BD-V4LX25MB) som i turtorail 1 og 2. Målet er å lage en enkelt RS232 transmitter som sender koden på DIP-bryterene til en terminal på PC'en. Du vil trenge hyperterminal eller et annet tilsvarende program til å lese COM porten på PC'en. === Lage nytt prosjekt === Start programmet "Project Navigator" under "Xilinx ISE 7.1i" menyen. Når du starter opp vil forrige prosjekt automatisk ligge der hvist noen har brukt ISE før deg. I tilfelle så lukker du prosjektet ved å velge "Close Project" under "File" menyen. Fra "file" menyen velger du så "New Project". Du vil nå få opp et vindu hvor du kan navngi prosjektet og velge plasering. Kall prosjektet "RS232" og finn en passende plasering for prosjektkatalogen. "Top Level Module Type" setter du til VHD. Trykk så "Next" [[Image:EDK_XPS_30.jpg]] Du vil nå få opp et vindu hvor du kan velge hviken FPGA du vil bruke, samt vertøyvalg. Sett "Device Family" til Virtex4, "Device" til "xc4vlx25", "Package" til "ff668" og "Speed Grade til -10". "Synthesis Tool" settes til "XST", "Simulator" til "ISE simulator" og simuleringsspråk settes til VHDL. Trykk så "Next". [[Image:EDK_XPS_31.jpg]] Du vil nå få opp ett vindu hvor du har muligheten til å få generert en kildefil til prosjektet. Trykk på "New Source". [[Image:EDK_XPS_32.jpg]] Velg "VHDL Module" og gi den navnet "RS232_main". Pass på at boksen "Add to Project" er merket og trykk "Next". [[Image:EDK_XPS_33.jpg]] Du kan nå legge til porter. Legg inn portene; clk, reset og send som "in". Legg til data som "in" og sett MSB til 7 og LSB til 0. Legg til port tx og opptatt som "out". Trykk så "Next". [[Image:EDK_XPS_34.jpg]] Du får nå opp et vindu med et samendrag av kildefilen din. Trykk "Finish". Du kommer nå tilbake til vinduet hvor du kan legge til kildefiler. Trykk "Next". Neste vindu lar deg legge til ferdige kilderfiler. Ta filene [[Media:rs232_clk.vhd">rs232_clk.vhd</a> og [[Media:rs232_tx.vhd">rs232_tx.vhd</a> og last dem ned på maskinen din. <pre> --------------------------------- --Tor Aleksander Birk Danielsen-- -- klokke til RS232 -- -- 10.04.2005 -- --------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity rs232_clk is port( clk : in std_logic; --main clk 100MHz reset : in std_logic; --global reset clk_tx : inout std_logic; --sendeklokke 16*baudrate bit_send : out std_logic); --pulstog 1*baudrate end rs232_clk; architecture Behavioral of rs232_clk is --interne tellere signal clk_teller_1 : std_logic_vector(0 to 8); signal clk_teller_2 : std_logic_vector(0 to 3); begin --------------------------------------- --lage klokkefrekvens på 16xbaudraten-- -- clk/(budrate*16) = tellerverdi*2-- -- 100MHz/(9600*32) = 325 = 101000101-- --------------------------------------- process (clk) begin if clk'event and clk='1' then if reset = '1' then clk_teller_1 <= clk_teller_1 + 1; if clk_teller_1 = "101000101" then clk_tx <= not clk_tx; clk_teller_1 <= "000000000"; end if; else clk_teller_1 <= "000000000"; end if; end if; end process; --------------------------------------- --lage 1/16 puls av clk_tx til sender-- -- dvs pulstog med samme frekvens -- -- som baudraten -- --------------------------------------- process (reset, clk_tx) begin if reset = '0' then bit_send <= '0'; clk_teller_2 <= "0000"; elsif rising_edge(clk_tx) then clk_teller_2 <= clk_teller_2 + 1; if clk_teller_2 = "1111" then bit_send <= '1'; elsif clk_teller_2 = "0000" then bit_send <= '0'; end if; end if; end process; end Behavioral; </pre> <pre> --------------------------------- --Tor Aleksander Birk Danielsen-- -- sender RS232 -- -- 10.04.2005 -- --------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity rs232_tx is port( clk_tx : in std_logic; --clk 16 * baudrateklokke reset : in std_logic; --global reset bit_send : in std_logic; --pulstog 1*baudrate send : in std_logic; --starter transmitt data : in std_logic_vector(7 downto 0); --data som skal sendes tx : out std_logic; --transmittpinne opptatt : out std_logic); --sender opptatt signal end rs232_tx; architecture Behavioral of rs232_tx is type tilstander is (idle, start_sending, sender, stop_send); signal sende_data : tilstander := idle; signal transmitt_buffer : std_logic_vector(9 downto 0); --transmitt buffer (10 bit) signal transmitt_data : std_logic_vector(7 downto 0); --inneholder databyte som skal sendes signal bit_teller: integer := 9; begin ------------------------- --senderutine for rs232-- ------------------------- sender_rs232: process (reset, clk_tx) begin if reset='0' then opptatt <= '0'; sende_data <= idle; transmitt_buffer <= (others=> '1'); elsif rising_edge(clk_tx) then case sende_data is when idle => if send = '0' then transmitt_data <= data; opptatt <= '1'; sende_data <= start_sending; else opptatt <= '0'; end if; when start_sending => if bit_send = '1' then sende_data <= sender; bit_teller <= 9; transmitt_buffer <= '1' & transmitt_data & '0'; end if; when sender => if bit_send = '1' then bit_teller <= bit_teller - 1; transmitt_buffer <= '1' & transmitt_buffer(transmitt_buffer'high downto 1); if bit_teller = 1 then sende_data <= stop_send; end if; end if; when stop_send => if bit_send = '1' then sende_data <= idle; end if; When others => sende_data <= idle; end case; end if; end process; tx <= transmitt_buffer(0); end Behavioral; </pre> Trykk så "Add Source" og legg begge filene til prosjektet. På spørsmål om filtype velg "VHDL design file". Trykk så "Next". [[Image:EDK_XPS_35.jpg]] Du vil nå få opp et sammendrag av prosjektet ditt. Trykk "Finish" og prosjektet vil bli generert. === Lage koden === Vi har nå en main fil samt en fil med klokkekode og en fil med transisjonskode. Neste steg bli å inkludere klokken og senderen i hovedfilene vår. Dobbeltklikk på filen "RS232_main.vhd" under "Module View" for å åpne filen for editering. Legg til følgende kodebit mellom "architecture .." og "begin": <pre> --legger til komponenter component rs232_clk port ( clk : in std_logic; reset : in std_logic; clk_tx : out std_logic; bit_send : out std_logic); end component; component rs232_tx port ( clk_tx : in std_logic; reset : in std_logic; bit_send : in std_logic; send : in std_logic; data : in std_logic_vector(7 downto 0); tx : out std_logic; opptatt : out std_logic); end component; --definere interne signaler signal bit_send : std_logic; signal clk_tx : std_logic; </pre> Etter begin legges følgende kodebit inn: <pre> -- kobler klokke og tx signaler til rs232_main entity sig. klokke_gen: rs232_clk port map( clk, reset, clk_tx, bit_send); transmitt: rs232_tx port map( clk_tx, reset, bit_send, send, data, tx, opptatt); </pre> Filen [[Media:RS232_main.vhd]] kan lastes ned ferdig hvis du er usikker på om du har lagt inn koden korrekt. Når du er ferdig med å redigere main filen tar du å lagrer prosjektet. Neste steg blir å test om koden er korekt. I "prosess View" vinduet går du til "Design Utilities" og dobbelklikker på "Check Syntax for Simulation". Har du gjort alt korekt skal du ikke få noen feilmelding nå. I "Module view" kan du også se at RS232_clk og RS232_tx har blitt underordnet RS232_main. === Legge til pinner === Neste steg er å legge til "user constraints" som i vårt tilfelle betyr å definere hvilke pinner som skal til hviken port. I "Module View" menyen markerer du filen RS232_main.vhd da det er denne filen du ønsker å legge "User Constraints" til. Når filen er markert går du til "Prosess View" vinduet og velger "User Constraints" menyen. Dobbeltklikk på "Assign Package Pins". Du vil nå få spørsmål om du vil legge til en UCF fil til prosjektet. Trykk "Yes". Du får nå opp et nytt vindu. I "Design Object List" vinduet har du en oversikt over alle IO porter i prosjektet ditt. Vi skal nå legge inn pinnr i "Loc" til hver av portene. Legg til følgene: [[Image:EDK_XPS_36.jpg]] Når du er ferdig lagrer du og avslutter hele 2Xilinx Pace" vinduet. Du har nå fått generert en UCF fil til prosjektet ditt som inneholder følgende: <pre> #PACE: Start of Constraints generated by PACE #PACE: Start of PACE I/O Pin Assignments NET "clk" LOC = "B13" ; NET "data<0>" LOC = "AD11" ; NET "data<1>" LOC = "AC12" ; NET "data<2>" LOC = "AC13" ; NET "data<3>" LOC = "AD13" ; NET "data<4>" LOC = "AC14" ; NET "data<5>" LOC = "AD14" ; NET "data<6>" LOC = "AC15" ; NET "data<7>" LOC = "AB7" ; NET "opptatt" LOC = "AE9" ; NET "reset" LOC = "AB9" ; NET "send" LOC = "AA11" ; NET "tx" LOC = "T7" ; #PACE: Start of PACE Area Constraints #PACE: Start of PACE Prohibit Constraints #PACE: End of Constraints generated by PACE </pre> === Sythesisering og Implementering === Neste steg blir å Synthesiserer og implementere deisgnet vårt. Marker igjen filen RS232_main.vhd i "Module View" vinduet og dobbeltklikk på "Genreate Programming File" i "Process View". Du vil nå få generert en bit fil som kan lastes over i FPGA'en. === Programmering og testing === Vi skal nå programmere FPGA'en. Sørg for at det er strøm på kortet og at programmeringsadapterert er koblet til. Start også hyperterminal med med en baudrate på 9600kbps. Gå til "Process View" og dobeltklikk på "Configure Device(iMPACT). Du åpner nå iMPACT programmet. På spørsmålom konfigurerig velg "Boundary-Scan mode". I neste vindu velger du automatisk tilkobling. Trykk så "Finish". iMPACT vil nå automatisk sjekke hvor mange og hvilke type FPGA'er som er koblet til programmeringsadapterert. Du vil få et vindu som sier at en enhet er funnet. Trykk "Ok". Du får nå opp et vindu der du blir bedt om å tilordne en new configureringsfil. Velg filen rs232_main.bit. Du får nå opp en advarsel. Ignorer denne og trykk "Ok". Høyreklikk på bildet av Virtex4 og velg "porgram...". Trykk så "Ok". Du vil nå programere FPGA'en. [[Image:EDK_XPS_37.jpg]] Hvis du nå trykker "Push2" bryteren vil du få bittmønsteret til DIP-bryterene oversendt til hyperterminal som ASCII kode. Du har nå suksessfult laget og implementert VHDL kode med ISE. [[Category:Mikroelektronikk]] cd07c1bb0a51ffafacfffd3b749e14900d2bdde6 0 104 216 2009-03-02T08:24:36Z Nfyku 4 New page: == Simple FLTK tutorial using Bloodshed Dev-C++ with MinGw == === Download Software === Get the latest version of Bloodshed Dev-C++ with Mingw/GCC from (~9 MB):<br/> http://www.bloodshed.... wikitext text/x-wiki == Simple FLTK tutorial using Bloodshed Dev-C++ with MinGw == === Download Software === Get the latest version of Bloodshed Dev-C++ with Mingw/GCC from (~9 MB):<br/> http://www.bloodshed.net/dev/devcpp.html<br/> or v-4.9.9.2 directly from:<br/> http://prdownloads.sourceforge.net/dev-cpp/devcpp-4.9.9.2_setup.exe<br/> Install in an appropriate place. After starting the program the first thing you need to do is to download the FLTK library. Go to “Tools->Check for updates / packages”. [[Image:webupdata.bmp]] Select devpak server “devpaks.org Community Devpaks” click “Check for updates” and check the fltk version 1.1.7 and click “Download selected” and continue with the installation of the library. 1.1.7 is a stable version of the FLTK library. FLTK2 is still a beta release. === Start a new FLTK project === Start Bloodshed Dev-C++ and start a new project “File->new-> project”. Choose “Empty Project” and give the project a name. [[Image:newproject.bmp]] Add a new source file to the project “File->new->Source File”. Save file as main.cpp. In order to setup the FLTK library for the project go to “Project->Project options” and add the following under the Parameters tab: <pre> Compiler: -DWIN32 -mms-bitfields Linker: -lfltk -lole32 -luuid -lcomctl32 -lwsock32 –lm </pre> [[Image:project_options.bmp]] Under the General tab choose Win32 GUI. [[Image:project_options2.bmp]] === The quick way of creating a FLTK project === “File->new-> project” and choose GUI and FLTK. This will automatically set up the linking and compiler setttings. [[Image:newproject2.bmp]] === Develop code === Create a new source file and write the following code: <pre> #include !<FL/Fl.H> #include \<FL/Fl_Window.H> int main (int argc , int **argv) { Fl_Window win(400,200,"Test"); //win(width, height,name) win.show(); // show window return(Fl::run()); //fltk application loop } </pre> Save and press F9 (Compile & Run) and a simple window will be created. [[Image:simplewindow.JPG]] ===Create a simple window with a button=== <pre> #include <FL/Fl.H> #include <FL/Fl_Window.H> #include <FL/Fl_Button.H> void but_cb(Fl_Widget* w, void*){ Fl_Button *b= (Fl_Button*)w; if (b->label() == "Off") { b->label("On"); }else{ b->label("Off"); } } int main (int argc , int **argv) { Fl_Window win(400,200,"Test"); //win(width, height,name) Fl_Button but(100,50,70,30,"On"); win.show(); // show window but.callback(but_cb); return(Fl::run()); //fltk application loop } </pre> [[Image:windowwithbutton.jpg]] [[Category:Mikroelektronikk]] 924e0383b30dffa72125e44acd946f5e84e457f4 0 105 217 2009-03-02T08:27:23Z Nfyku 4 New page: [[http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow]] [[http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial]] ... wikitext text/x-wiki [[http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow]] [[http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial]] [[http://pages.cs.wisc.edu/~david/courses/cs755/cs755/ VLSI System Design course with tutorials]] [[Category:Mikroelektronikk]] 1b2ff6c56923e8b7565adb9dc16c2c86af6f5646 0 25 218 2009-03-02T08:35:04Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System [[Category:Mikroelektronikk]] 5f4bca04dde5fe8d27839fc575d591b1ff07ac93 2 106 219 2009-03-03T06:47:46Z Dfe002 7 New page: This is the personal page from Dag Toppe Larsen. wikitext text/x-wiki This is the personal page from Dag Toppe Larsen. 0eedac7417a9f7e5bb5ae9e6feecba893f7914ad 220 2009-03-03T06:48:00Z Dfe002 7 wikitext text/x-wiki This is the personal page from Heidi Sandaker a24481dcb873bc165eba3e8a30d48e7b6934196f 2 107 221 2009-03-03T06:48:59Z Dfe002 7 New page: This is the personal page from Thomas Burgess. wikitext text/x-wiki This is the personal page from Thomas Burgess. 7e03fa04d6d5a0344a8868017243b8566a9288e0 2 108 222 2009-03-03T06:51:23Z Dfe002 7 New page: This is the personal page from Lars Gimmestad Johansen. wikitext text/x-wiki This is the personal page from Lars Gimmestad Johansen. 60a959d940c14f7e1aa81091702798b4c61c4202 2 109 223 2009-03-03T10:48:54Z Dfe002 7 New page: This is the personal page from Dieter Röhrich. wikitext text/x-wiki This is the personal page from Dieter Röhrich. d38d47b118ddda1a9701aec12a717662ad14ef6d 3 110 224 2009-03-03T12:31:49Z St12361 17 New page: === RS 232-Setting === Baud Rate: 9600 Parity: None Data Bits: 8 Stop Bits: 1 Flow Control: None wikitext text/x-wiki === RS 232-Setting === Baud Rate: 9600 Parity: None Data Bits: 8 Stop Bits: 1 Flow Control: None 181c226a5d0da57f3336714f7dd70398c19b595b 0 111 227 2009-03-03T13:21:22Z St12361 17 New page: {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG... wikitext text/x-wiki {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} e2c5438906198c150a3b6fc5e34fc0ee7b4f5638 229 2009-03-04T07:14:47Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |[[http://www.farnell.com/datasheets/84674.pdf DataSheet]] |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2718 |VME bridge | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME bridge | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} 4e3935a9ebce06769ecee3b1890a3027fdeaa549 230 2009-03-04T07:29:41Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |[[http://www.farnell.com/datasheets/84674.pdf DataSheet]] |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} f29302232c85f5def62efe3bf6df7ebb55996d1f 0 112 228 2009-03-03T14:00:07Z St12361 17 New page: This how to is based on using the functionality of the custome Labview VI's. Refer to the User Manual for using the Terminal interface of the unit. === RS 232-Setting === Baud Rate: ... wikitext text/x-wiki This how to is based on using the functionality of the custome Labview VI's. Refer to the User Manual for using the Terminal interface of the unit. === RS 232-Setting === Baud Rate: 9600 Parity: None Data Bits: 8 Stop Bits: 1 Flow Control: None a7681f5e82fed2d69b0dd57544371f1d5663616a 232 2009-03-06T13:26:09Z St12361 17 wikitext text/x-wiki This how to is based on using the functionality of the custome Labview VI's. Refer to the User Manual for using the Terminal interface of the unit. === RS 232-Setting === Baud Rate: 9600 Parity: None Data Bits: 8 Stop Bits: 1 Flow Control: None Kladd min. write time between commands: 60ms (30 ms worst case) Bytes recieved (From top Menu @ 9600 bauds) "1": 256 bytes (220 ms) "1+b": 170 bytes (150 ms) "1+b+a": 273 bytes (230 ms) "1+b+a+n": 272 bytes (230 ms) "1+b+a+c/i/j..": 14 bytes (15 ms) "1+b+a+c/i/j..+X": 1 bytes (1 ms) "1+b+a+c/i/j..+X+/r/n": 272 bytes (230 ms) cdd31d9c691b1062d877edb4c06972b9b3cd75ba 2 113 231 2009-03-04T07:32:37Z Dfe002 7 New page: This is the personal page from Hege Austrheim Erdal. wikitext text/x-wiki This is the personal page from Hege Austrheim Erdal. d2b031b21ccdf3f0e85831d1c0e4ec2f057dd373 2 114 233 2009-03-09T07:06:33Z Dfe002 7 New page: This is the personal page from Andreas Tefre Samnøy. wikitext text/x-wiki This is the personal page from Andreas Tefre Samnøy. 8817e836fe66fe70dc4c606cfbed3b64024c77b6 0 23 234 2009-03-09T07:29:00Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... [[Category:Detector lab]] babd559a9f26285760448a394db687e6fae14d36 0 115 235 2009-03-09T07:51:22Z Dfe002 7 New page: ==How to set up a general 3D system== ===General overview=== As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the da... wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. Figure I.2 : Device Manager Window ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. Figure I.3 : VME-MXI-2 Controller board (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. Figure I.4 : Turbo pixel low level board To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager Figure I.5 : MAX screenshot of how to start Resman figure I.6 : Tree configuration After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device” (cf Figure I.7). A new window appears and by following the steps the device is installed. Figure I.7 : How to create a new VME device The first step is to choose the pseudo logical address to “256” (cf Figure I.8.a). The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device (cf Figure I.8.b). For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. (a) (b) Figure I.8 How to enter the parameters for a new VME device At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. Figure I.9 : Final tree architecture We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) ===I.5. TPCC board=== Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Figure I.10 : TPCC board Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot (cf Figure I.12). Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. Figure I.12 : Bump bonded The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. Figure I.13 : Front End electronic board We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== Figure II.1 : TurboDAQ main panel To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. On Figure II.1 we observe the TurboDAQ main panel. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. (cf Figure II.2) If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. == 6f775d8184928171263c691b817333482a4b3ee8 236 2009-03-09T08:31:13Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. Figure I.2 : Device Manager Window ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. Figure I.3 : VME-MXI-2 Controller board (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. Figure I.4 : Turbo pixel low level board To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager Figure I.5 : MAX screenshot of how to start Resman figure I.6 : Tree configuration After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device” (cf Figure I.7). A new window appears and by following the steps the device is installed. Figure I.7 : How to create a new VME device The first step is to choose the pseudo logical address to “256” (cf Figure I.8.a). The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device (cf Figure I.8.b). For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. (a) (b) Figure I.8 How to enter the parameters for a new VME device At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. Figure I.9 : Final tree architecture We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) ===I.5. TPCC board=== Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Figure I.10 : TPCC board Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot (cf Figure I.12). Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. Figure I.12 : Bump bonded The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. Figure I.13 : Front End electronic board We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== Figure II.1 : TurboDAQ main panel To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. On Figure II.1 we observe the TurboDAQ main panel. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. (cf Figure II.2) If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. 857c13eb291a45875223c1bcdf7b2c9e081d40d5 237 2009-03-09T08:32:15Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. Figure I.2 : Device Manager Window ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. Figure I.3 : VME-MXI-2 Controller board (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. Figure I.4 : Turbo pixel low level board To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager Figure I.5 : MAX screenshot of how to start Resman figure I.6 : Tree configuration After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device” (cf Figure I.7). A new window appears and by following the steps the device is installed. Figure I.7 : How to create a new VME device The first step is to choose the pseudo logical address to “256” (cf Figure I.8.a). The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device (cf Figure I.8.b). For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. (a) (b) Figure I.8 How to enter the parameters for a new VME device At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. Figure I.9 : Final tree architecture We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) ===I.5. TPCC board=== Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Figure I.10 : TPCC board Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot (cf Figure I.12). Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. Figure I.12 : Bump bonded The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. Figure I.13 : Front End electronic board We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== Figure II.1 : TurboDAQ main panel To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. On Figure II.1 we observe the TurboDAQ main panel. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. (cf Figure II.2) If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. ff10facc9b4a31b3a33b75028069d1ed81125e09 6 116 238 2009-03-09T09:18:29Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 117 239 2009-03-09T09:18:39Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 118 240 2009-03-09T09:18:47Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 119 241 2009-03-09T09:18:53Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 120 242 2009-03-09T09:18:59Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 121 243 2009-03-09T09:19:10Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 122 244 2009-03-09T09:19:18Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 123 245 2009-03-09T09:19:26Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 124 246 2009-03-09T09:19:38Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 125 247 2009-03-09T09:19:46Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 126 248 2009-03-09T09:19:53Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 127 249 2009-03-09T09:20:00Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 128 250 2009-03-09T09:20:07Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 129 251 2009-03-09T09:20:15Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 130 252 2009-03-09T09:20:22Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 131 253 2009-03-09T09:20:29Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 115 254 2009-03-09T09:51:53Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== <center>[[Image:3D_overview.JPG|frame|200px|Overview]]</center> As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device” (cf Figure I.7). A new window appears and by following the steps the device is installed. <gallery> File:3D_createnewvmedevice.JPG File:3D_entervmeparameters1.JPG File:3D_entervmeparameters2.JPG </gallery> The first step is to choose the pseudo logical address to “256” (cf Figure I.8.a). The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device (cf Figure I.8.b). For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. (a) (b) Figure I.8 How to enter the parameters for a new VME device At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. Figure I.9 : Final tree architecture We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) ===I.5. TPCC board=== Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Figure I.10 : TPCC board Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot (cf Figure I.12). Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. Figure I.12 : Bump bonded The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. Figure I.13 : Front End electronic board We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== Figure II.1 : TurboDAQ main panel To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. On Figure II.1 we observe the TurboDAQ main panel. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. (cf Figure II.2) If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. 08e2ba7a81ea15207673d0f3985c0d872f18aec3 255 2009-03-09T10:17:03Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== <center>[[Image:3D_overview.JPG|frame|200px|Overview]]</center> As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. Figure I.9 : Final tree architecture We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) ===I.5. TPCC board=== Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Figure I.10 : TPCC board Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot (cf Figure I.12). Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. Figure I.12 : Bump bonded The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. Figure I.13 : Front End electronic board We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== Figure II.1 : TurboDAQ main panel To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. On Figure II.1 we observe the TurboDAQ main panel. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. (cf Figure II.2) If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. a2778bd3a4d0148f0e0aee84afefac3c741da0f9 256 2009-03-09T10:38:12Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== <center>[[Image:3D_overview.JPG|frame|200px|Overview]]</center> As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) <center>[[Image:3D_finalvmestructure.JPG|frame|200px|Final VME structure]]</center> ===I.5. TPCC board=== [[Image:3D_tpccboard.JPG|thumb|right|250px|Turbo Pixel Control Card]] Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot (cf Figure I.12). Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. Figure I.12 : Bump bonded The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. Figure I.13 : Front End electronic board We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== Figure II.1 : TurboDAQ main panel To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. On Figure II.1 we observe the TurboDAQ main panel. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. (cf Figure II.2) If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. 8b7756c2cd9862e5afaed9495a39b759d31e12ff 258 2009-03-09T12:30:11Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== <center>[[Image:3D_overview.JPG|frame|200px|Overview]]</center> As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) <center>[[Image:3D_finalvmestructure.JPG|frame|200px|Final VME structure]]</center> ===TPCC board=== [[Image:3D_tpccboard.JPG|thumb|right|250px|Turbo Pixel Control Card]] Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot. Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. The TurboDAQ main panel comes up. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. <gallery caption='TurboDAQ screenshots'> Image:3D_turbodaq_initialisation.JPG|Initialisation panel Image:3D_turbodaq_configuration.JPG|Configuration panel Image:3D_turbodaq_datacontrol.JPG|Control panel Image:3D_turbodaq_datafitting.JPG|Datafitting panel Image:3D_turbodaq_scancontrol.JPG|Scancontrol panel Image:3D_turbodaq_onlineplot.JPG|Onlineplot panel </gallery> ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==3D sensor types== [[Image:3D_sensortypes.JPG|thumb|center|400px|Different types of 3D sensors]] ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. 2b0fdd20b77b0d5f4a9889b1c64595220c8da27b 259 2009-03-09T12:31:21Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== [[Image:3D_overview.JPG|noframe|400px|center|Overview]] As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) <center>[[Image:3D_finalvmestructure.JPG|frame|200px|Final VME structure]]</center> ===TPCC board=== [[Image:3D_tpccboard.JPG|thumb|right|250px|Turbo Pixel Control Card]] Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot. Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. The TurboDAQ main panel comes up. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. <gallery caption='TurboDAQ screenshots'> Image:3D_turbodaq_initialisation.JPG|Initialisation panel Image:3D_turbodaq_configuration.JPG|Configuration panel Image:3D_turbodaq_datacontrol.JPG|Control panel Image:3D_turbodaq_datafitting.JPG|Datafitting panel Image:3D_turbodaq_scancontrol.JPG|Scancontrol panel Image:3D_turbodaq_onlineplot.JPG|Onlineplot panel </gallery> ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==3D sensor types== [[Image:3D_sensortypes.JPG|thumb|center|400px|Different types of 3D sensors]] ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. c7f15684e29f7f272de95a00a3ab6db8d7306fd8 262 2009-03-09T13:12:46Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== [[Image:3D_overview.JPG|noframe|400px|center|Overview]] As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) <center>[[Image:3D_finalvmestructure.JPG|frame|200px|Final VME structure]]</center> ===TPCC board=== [[Image:3D_tpccboard.JPG|thumb|right|250px|Turbo Pixel Control Card]] Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. [[Image:3D_tpccpower.JPG|thumb|right|250px|Power connector on the TPCC board]] [[Image:3D_fepower2.JPG|thumb|right|250px|Power connector for the FE on the TPCC board]] Pinning on the TPCC connector: #GND VDDD #GND VDDA #VDDD -5V, 0.5A #VDDA +5V, 1.6A Pinning on the FE connector on the TPCC: #GND VDDD #GND VDDA #VDDD +2V, 65mA #VDDA +1.6V, 30mA You can identify pin 1 on the TPCC with the small yellow dot behind the connector close to one leg. The pictures look at the connectors on the TPCC board with the retention nose pointing upwards (flip the board for the FE power). ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot. Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. The TurboDAQ main panel comes up. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. <gallery caption='TurboDAQ screenshots'> Image:3D_turbodaq_initialisation.JPG|Initialisation panel Image:3D_turbodaq_configuration.JPG|Configuration panel Image:3D_turbodaq_datacontrol.JPG|Control panel Image:3D_turbodaq_datafitting.JPG|Datafitting panel Image:3D_turbodaq_scancontrol.JPG|Scancontrol panel Image:3D_turbodaq_onlineplot.JPG|Onlineplot panel </gallery> ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==3D sensor types== [[Image:3D_sensortypes.JPG|thumb|center|400px|Different types of 3D sensors]] ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. 11662c62b107e35ac23cc540e60c686b1a0a8554 266 2009-03-09T13:31:13Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== [[Image:3D_overview.JPG|noframe|400px|center|Overview]] As we can see on Figure I.1, the measurement system consist of one computer with software to pilot the system and treat the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board (cf Figure I.3), from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. (cf Figure I.4) This board is single width, 6U, using 32 bit transfers. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we install drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lighted in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces (cf Figure I.6) and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next windows we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture in Figure I.9. Each device should have a correct resource memory. We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) <center>[[Image:3D_finalvmestructure.JPG|frame|200px|Final VME structure]]</center> ===TPCC board=== [[Image:3D_tpccboard.JPG|thumb|right|250px|Turbo Pixel Control Card]] Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board (cf Figure I.10). This bridge transfers the data to the TPLL which convert it to be transmitting on the VMEbus. Contrary to TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shield cables with Molex connector could be used. Figure I.11 show the two connectors plugged in TPCC. TPCC supplies the TPCC board; it is connected near the multicolor ribbon cable. FE connector is plugged on the TPCC back and supply the Front end card. Be careful with the power, both voltage and current it is very important to check it and respect the voltage. [[Image:3D_tpccpower2.JPG|thumb|right|250px|Power connector on the TPCC board]] [[Image:3D_fepower3.JPG|thumb|right|250px|Power connector for the FE on the TPCC board]] Pinning on the TPCC connector: #GND VDDD #GND VDDA #VDDD -5V, 0.5A #VDDA +5V, 1.6A Pinning on the FE connector on the TPCC: #GND VDDD #GND VDDA #VDDD +2V, 65mA #VDDA +1.6V, 30mA You can identify pin 1 on the TPCC with the small yellow dot behind the connector close to one leg. The pictures look at the connectors on the TPCC board with the retention nose pointing upwards (flip the board for the FE power). ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot. Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. Shown in Figure I.13, the 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from TPCC too. We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to pilot the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer ===TurboDAQ start=== To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. The TurboDAQ main panel comes up. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right of the Figure II.2 shutting down and a new orange LED switching on near the FE flat cable. Moreover the values in the Figure II.3 appeared, else an error message appears. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement (cf Figure II.4). Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. <gallery caption='TurboDAQ screenshots'> Image:3D_turbodaq_initialisation.JPG|Initialisation panel Image:3D_turbodaq_configuration.JPG|Configuration panel Image:3D_turbodaq_datacontrol.JPG|Control panel Image:3D_turbodaq_datafitting.JPG|Datafitting panel Image:3D_turbodaq_scancontrol.JPG|Scancontrol panel Image:3D_turbodaq_onlineplot.JPG|Onlineplot panel </gallery> ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==3D sensor types== [[Image:3D_sensortypes.JPG|thumb|center|400px|Different types of 3D sensors]] ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. 59b4ca0e3d3c244d267a054f40c8c43ba8701da2 6 132 257 2009-03-09T12:26:09Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 133 260 2009-03-09T12:54:09Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 111 263 2009-03-09T13:22:21Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |[[http://www.farnell.com/datasheets/84674.pdf DataSheet]] |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} 3e8b1156153d5d041c792508e21030bbaeec92c3 6 135 264 2009-03-09T13:30:30Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 136 265 2009-03-09T13:30:37Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 23 267 2009-03-09T13:40:07Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... [[Category:Detector lab]] 5a73231e10a9450eb2408b9f72164f483381e5bc 268 2009-03-09T13:43:21Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, Ahmed ... ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] bfae699ee478fd08a673a92187bebda7c16a4e9f 0 137 269 2009-03-09T14:16:37Z Tbu082 19 New page: == Particle Physics == Wiki page for Bergen University Particle Physics Group. Projects [[Image:atlas_banner.jpg]] wikitext text/x-wiki == Particle Physics == Wiki page for Bergen University Particle Physics Group. Projects [[Image:atlas_banner.jpg]] 9cda23e37e3d1cacaf354032208794c5c0d6ffbb 271 2009-03-09T14:19:29Z Tbu082 19 wikitext text/x-wiki == Particle Physics == Wiki page for Bergen University Particle Physics Group. Projects [http://www.uib.no/fg/subatom/prosjekter/atlas|[[Image:atlas_banner.jpg]]] 1bf6e9d73a37a9487481ceeb113e92ab233ecc2e 272 2009-03-09T14:20:31Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas|Atlas Bergen UiB page]]. 539b2e7dbd08c6336aa8e092a9bb9f62de17429e 273 2009-03-09T14:23:20Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas|Atlas Bergen UiB page]]. Last changes: [[User:Tbu082|Tbu082]] 15:23, 9 March 2009 (CET) 2fff9a23f6da22e7d18ce7f0f30544a5cd0b815e 274 2009-03-09T14:27:21Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas|Atlas Bergen UiB page]]. === [[Meetings]] === Last changes: [[User:Tbu082|Tbu082]] 991c023fc4b8bcefaec9f9ab27a0aad6e745ab41 275 2009-03-09T14:27:44Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas|Atlas Bergen UiB page]]. === [[ParticlePhysicsGroupMeetings|Meetings]] === Last changes: [[User:Tbu082|Tbu082]] 5562a71f8a4335ae3cbb9e8628dd1c30e4666375 6 138 270 2009-03-09T14:16:50Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 139 276 2009-03-09T14:29:33Z Tbu082 19 New page: == Particle Physics Group Meetings == [SUSYTauMeeting_12march2009|SUSY/Tau analysis meeting 12/3-09] wikitext text/x-wiki == Particle Physics Group Meetings == [SUSYTauMeeting_12march2009|SUSY/Tau analysis meeting 12/3-09] 3e44cf5f51657e83d0fd40445046119e6b01210c 277 2009-03-09T14:29:43Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == [[SUSYTauMeeting_12march2009|SUSY/Tau analysis meeting 12/3-09]] 4bbd3b4965caa1ec49766643d9cb5c8ed97e48fe 291 2009-03-09T14:36:35Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == [[SUSY/Tau analysis meeting March 12, 2009]] 238f598a2be12ced883b763f367642891f4546ba 0 140 278 2009-03-09T14:30:23Z Tbu082 19 New page: # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if ... wikitext text/x-wiki # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB 9dbe3f947eaeb8f9e210b3fd841b7c308d9b40f6 279 2009-03-09T14:30:39Z Tbu082 19 wikitext text/x-wiki # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481|http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB dc3fdc452647c7dd198357375c90dfd96346ef4d 280 2009-03-09T14:31:14Z Tbu082 19 wikitext text/x-wiki # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [indico|http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB 1e8cf83c7104eee674fcdb5411a1f5fc6382ca03 281 2009-03-09T14:31:26Z Tbu082 19 wikitext text/x-wiki # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB 422b14559f3705e77ff61810614eaaa5fa0ea49b 282 2009-03-09T14:31:38Z Tbu082 19 wikitext text/x-wiki # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481|indico] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB 36a7fe0f207e3505e69f5396f3c20f0aa2c3e567 283 2009-03-09T14:31:52Z Tbu082 19 wikitext text/x-wiki # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481indico] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB e1c205ff9ae3ef56be756097aecb8ebb2237fdee 284 2009-03-09T14:32:20Z Tbu082 19 wikitext text/x-wiki # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB 8d9bb1d8069a30181c22325316cec38c65be9606 285 2009-03-09T14:33:23Z Tbu082 19 wikitext text/x-wiki == SUSY/Tau analysis meeting March 12, 2009 == === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === ae69fb3cbc9a1a7f7711a09f020cd54c6cdbb23c 286 2009-03-09T14:33:57Z Tbu082 19 [[SUSYTauMeeting 12march2009]] moved to [[SUSY/Tau analysis meeting March 12, 2009]]: unreadable title wikitext text/x-wiki == SUSY/Tau analysis meeting March 12, 2009 == === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === ae69fb3cbc9a1a7f7711a09f020cd54c6cdbb23c 288 2009-03-09T14:34:35Z Tbu082 19 wikitext text/x-wiki === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === [[User:Tbu082|Tbu082]] 15:34, 9 March 2009 (CET) 0bc26307f59f1c3d4942bea40eac46691beb4c56 289 2009-03-09T14:35:30Z Tbu082 19 wikitext text/x-wiki === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === --- ''[[User:Tbu082|Tbu082]] 15:34, 9 March 2009 (CET)'' d72eab9ed7373727383e2477c1ec1eb52b4f4c09 290 2009-03-09T14:35:49Z Tbu082 19 wikitext text/x-wiki === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Thomas Burgess]] 15:34, 9 March 2009 (CET)'' e2e3f1bf8cce6b297e752407f6592b1a359eaef1 292 2009-03-09T14:40:49Z Tbu082 19 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (XX-XX-XX) and in the Bergen Evo room (next to Bjarnes office) === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Thomas Burgess]] 15:34, 9 March 2009 (CET)'' eeeefbdb0778c1af223f61074c8d433b6814f6c9 0 141 287 2009-03-09T14:33:57Z Tbu082 19 [[SUSYTauMeeting 12march2009]] moved to [[SUSY/Tau analysis meeting March 12, 2009]]: unreadable title wikitext text/x-wiki #REDIRECT [[SUSY/Tau analysis meeting March 12, 2009]] b443ffc5d33b718206fc08dcd0f7adc535c60038 2 142 293 2009-03-09T15:20:51Z Tbu082 19 New page: == Arshak Tonoyan == wikitext text/x-wiki == Arshak Tonoyan == bba6c393a33467f8da4bfa9e0987d55941ecedc0 294 2009-03-09T15:23:30Z Ato061 22 wikitext text/x-wiki == Arshak Tonoyan == [[Image:arshak.jpg]] 2f807d47562117f5694ed1751b518a2bf8360a78 6 143 295 2009-03-09T15:23:53Z Ato061 22 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2 107 296 2009-03-09T15:26:40Z Tbu082 19 wikitext text/x-wiki This is the personal page from Thomas Burgess. See my [http://tburgess.web.cern.ch/tburgess/ CERN] or http://www.uib.no/personer/Thomas.Burgess UiB] web pages for more information 894192728d196caba4c4435ef84d1dab47a3755d 297 2009-03-09T15:26:52Z Tbu082 19 wikitext text/x-wiki This is the personal page from Thomas Burgess. See my [http://tburgess.web.cern.ch/tburgess/ CERN] or [http://www.uib.no/personer/Thomas.Burgess UiB] web pages for more information a074c2de66c76643c1599989e35c3a34df6f8153 0 36 298 2009-03-09T23:17:04Z St12361 17 corrected entity reference for alu_tb wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> f243d279f762fb5edb2ad5f4687c186d06f74380 299 2009-03-09T23:18:58Z St12361 17 Undo revision 298 by [[Special:Contributions/St12361|St12361]] ([[User talk:St12361|Talk]]) wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> 61671d970b8af5ef304ba9032b96c02dd0eef3c1 6 144 300 2009-03-10T10:25:41Z Her065 20 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 302 2009-03-10T10:32:49Z Her065 20 Unprotected "[[Image:Linearity 030209.pdf]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2 113 301 2009-03-10T10:30:21Z Her065 20 wikitext text/x-wiki This is the personal page for Hege Austrheim Erdal. 4454ff186cdc07fa431e13fbbbd5df39dbfc4204 0 21 303 2009-03-10T10:32:57Z Her065 20 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf‎ Hege: Linearity Results 03.02.09] ad7d322a5c0cf7f88599c45b00aaf7eb66920361 0 21 304 2009-03-10T10:33:52Z Her065 20 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] 0303c02f262350622eea6e206beb7e829e95b2e1 0 140 305 2009-03-10T11:51:22Z Ato061 22 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Thomas Burgess]] 15:34, 9 March 2009 (CET)'' 286948f5edb5f15ed365cd8a15521f645d7b713c 333 2009-03-11T10:36:50Z Tbu082 19 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== Title: BergenSUSY Description: Bergen SUSY/Tau meeting Community: ATLAS Password: SUSYBergen Time: 2009-03-12 08:30-10:30 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Thomas Burgess]] 15:34, 9 March 2009 (CET)'' f49eca103bc3f83d788c77cb547314d2b60276dd 334 2009-03-11T10:37:35Z Tbu082 19 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== Title: BergenSUSY Description: Bergen SUSY/Tau meeting Community: ATLAS Password: SUSYBergen Time: 2009-03-12 08:30-10:30 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Tbu082]] 11:37, 11 March 2009 (CET)''' [[Category:Particle Physics]] 55ca39a04eca22bb62a4f1950f980d9114e98cdf 335 2009-03-11T10:40:44Z Ato061 22 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== '''Title: BergenSUSY Description: Bergen SUSY/Tau meeting Community: ATLAS Password: SUSYBergen Time: 2009-03-12 08:30-10:30''' Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Tbu082]] 11:37, 11 March 2009 (CET)''' [[Category:Particle Physics]] dac66a1542f62fa1f93610d43b3a879c16b757a1 336 2009-03-11T10:42:03Z Ato061 22 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== * Title: BergenSUSY * Description: Bergen SUSY/Tau meeting * Community: ATLAS * Password: SUSYBergen * Time: 2009-03-12 08:30-10:30 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Tbu082]] 11:37, 11 March 2009 (CET)''' [[Category:Particle Physics]] ada241d630521b8edc4333a066ad18f9d9f2fd9c 337 2009-03-11T10:42:50Z Ato061 22 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== * '''Title''': BergenSUSY * '''Description''': Bergen SUSY/Tau meeting * '''Community''': ATLAS * '''Password''': SUSYBergen * '''Time''': 2009-03-12 08:30-10:30 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB === Notes === -Last changed ''[[User:Tbu082|Tbu082]] 11:37, 11 March 2009 (CET)''' [[Category:Particle Physics]] f04d3c91efedc820e71838174638756bff7b19cf 359 2009-03-12T07:58:40Z Kka054 24 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== * '''Title''': BergenSUSY * '''Description''': Bergen SUSY/Tau meeting * '''Community''': ATLAS * '''Password''': SUSYBergen * '''Time''': 2009-03-12 08:30-10:30 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB [[analysis1203.pdf]] === Notes === -Last changed ''[[User:Tbu082|Tbu082]] 11:37, 11 March 2009 (CET)''' [[Category:Particle Physics]] 6535a8b767fa23adde5c863656fa2f823fb0c677 360 2009-03-12T07:59:29Z Kka054 24 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== * '''Title''': BergenSUSY * '''Description''': Bergen SUSY/Tau meeting * '''Community''': ATLAS * '''Password''': SUSYBergen * '''Time''': 2009-03-12 08:30-10:30 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB [[media:analysis1203.pdf]] === Notes === -Last changed ''[[User:Tbu082|Tbu082]] 11:37, 11 March 2009 (CET)''' [[Category:Particle Physics]] 8e558e6438658fffd01f5dcdd74474ffdffeda03 364 2009-03-12T08:09:24Z Tbu082 19 wikitext text/x-wiki === Connecting === The meeting will be held 9:00-10:00 on Thursday, 12th of March, 2009. You can connect via EVO, meeting name is BergenSUSY. Multi user connections will be available at CERN (40-R-C10) and in the Bergen Evo room (next to Bjarnes office) ==== EVO Details ==== * '''Title''': BergenSUSY * '''Description''': Bergen SUSY/Tau meeting * '''Community''': ATLAS * '''Password''': SUSYBergen * '''Time''': 2009-03-12 08:30-10:30 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eDeae8vBvta9atIMaIID - Phone Bridge ID: 852331 Password: 7865 EVO Phone Bridge Telephone Numbers: --------------- * USA (Caltech, Pasadena, CA) +1 626 395 2112 * Switzerland (CERN, Geneva) +41 22 76 71400 * Slovakia (UPJS, Kosice) +421 55 234 2420 * Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge * Germany (DESY, Hamburg) +49 40 8998 1340 * USA (BNL, Upton, NY) +1 631 344 6100 * United Kingdom (University of Manchester) +44 161 306 6802 === Agenda === # SUSY analysis, current work and what remains (Alex and Therese) # Background analysis -- top bg with emphasis on taus from top; this is something master students can contribute to if they want and we can present the results on the coming "SUSY top bg" meetings (Semi-leptonic top at high mT focus meeting); see the last meeting: [http://indico.cern.ch/conferenceDisplay.py?confId=52481] (Therese makes a small intro on what is interesting here, and we can have a discussion about it) # Data production and computer resources in Bergen (Alex and Thomas) # AOB [[media:Analysis_1203.pdf]] === Notes === -Last changed ''[[User:Tbu082|Tbu082]] 11:37, 11 March 2009 (CET)''' [[Category:Particle Physics]] 8aeca6900fe7623406a43ee7d40dff9c25fe112c 0 115 306 2009-03-10T14:40:55Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== [[Image:3D_overview.JPG|noframe|400px|center|Overview]] The measurement system consist of one computer with software to control the system and collect the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board, from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. This board is single width, 6U, using 32 bit transfer. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we need to install some drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lit in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is a yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next window we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture. Each device should have a correct resource memory. We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) <center>[[Image:3D_finalvmestructure.JPG|frame|200px|Final VME structure]]</center> ===TPCC board=== [[Image:3D_tpccboard.JPG|thumb|right|250px|Turbo Pixel Control Card]] Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board. This bridge transfers the data to the TPLL which convert it to be transmitted on the VMEbus. Contrary to the TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shielded cables with Molex connectors should be used. The figures show the two connectors plugged in TPCC. The TPCC power cable supplies the TPCC board; it is connected near the multicolor ribbon cable. The FE power connector is plugged on the TPCC back and supplies the Front end card. Be careful with the power, both voltage and current is very important to check and respect the voltage. [[Image:3D_tpccpower2.JPG|thumb|right|250px|Power connector on the TPCC board]] [[Image:3D_fepower3.JPG|thumb|right|250px|Power connector for the FE on the TPCC board]] Pinning on the TPCC connector: #GND VDDD #GND VDDA #VDDD -5V, 0.5A #VDDA +5V, 1.6A Pinning on the FE connector on the TPCC: #GND VDDD #GND VDDA #VDDD +2V, 65mA #VDDA +1.6V, 30mA You can identify pin 1 on the TPCC with the small yellow dot behind the connector close to one leg. The pictures look at the connectors on the TPCC board with the retention nose pointing upwards (flip the board for the FE power). ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot. Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. The 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from the TPCC. We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to control the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer. ===TurboDAQ start=== To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. The TurboDAQ main panel comes up. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. If "resman" is not run, TurboDAQ will crash during initialisation. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right shutting down and a new orange LED switching on near the FE flat cable. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement. Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill a value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. <gallery caption='TurboDAQ screenshots'> Image:3D_turbodaq_initialisation.JPG|Initialisation panel Image:3D_turbodaq_configuration.JPG|Configuration panel Image:3D_turbodaq_datacontrol.JPG|Control panel Image:3D_turbodaq_datafitting.JPG|Datafitting panel Image:3D_turbodaq_scancontrol.JPG|Scancontrol panel Image:3D_turbodaq_onlineplot.JPG|Onlineplot panel </gallery> ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==3D sensor types== [[Image:3D_sensortypes.JPG|thumb|center|400px|Different types of 3D sensors]] ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. ed0119a6930343d58a1992b81e8927923ad5ba20 361 2009-03-12T08:03:56Z Dfe002 7 wikitext text/x-wiki ==How to set up a general 3D system== ===General overview=== [[Image:3D_overview.JPG|noframe|400px|center|Overview]] The measurement system consist of one computer with software to control the system and collect the data, one VME crate with controller board and a board (TPLL) to clock the signal and transfer the data, one data acquisition board (TPCC), one electronic card to read-out the signal from the detector and three power supplies. Below is a list of the hardware and software components of this system: * Computer HP with Windows XP machine * TurbDAQ 6.6 software (cf part II of this report) * PCI-MXI-2 National Instrument * VME crate WES * VME-MXI-2 controller National Instrument * MXI-2 cable * Turbo pixel low level card (TPLL) * Turbo pixel control card (TPCC) * 2 flat cables * Front End electronic board * 1 High power supply Keithley 487 * 1 Lemo cable with adaptor * 2 Low power supply Oltronix B703DT * 2 Shield cables for electric supply ===PCI-MXI-2=== [[Image:3D_devicemanagerwindow.JPG|thumb|right|300px|Device Manager Window]] A PCI-MXI-2 is plugged on the PCI slot 1 of the computer mother board. This card is the interface between the computer and the VME. The installation can be started from the following path: Computer properties * Hardware ** Device Manager *** VXI Interface This opens the properties of the PCI-VXI card and under Driver tab we can upload the plug-and-play driver to start the installation of the PCI card. ===VME system=== The VME controller board, from National Instruments, has to plug in the first slot of the VME crate to control the VMEbus (Vesa Modular Eurocard bus). The connection between Computer and VME is carried out through MXI-2 cable plugged in PCI card and in the VME-MXI-2 controller board. (Do not modify the switch on the board because it used in case of “controller board”, the switches U20 is used for slave mode of the board) We plug another VME card in the crate, the TPLL board, which is used for clock generation and synchronization, data FIFO, trigger FIFO, 16 Mbytes board SRAM support module level histogramming, FPGA for encoding/decoding the MCC serial data protocol. This board is single width, 6U, using 32 bit transfer. To configure the VMEbus and the TPLL properly you need to install the following National Instrument software and driver: * Measurement and Automation (MAX version 4.5) * NI-VXI (version 3.5.1) * NI-VISA (with MAX 4.5) [[Image:3D_startingresman.JPG|thumb|right|250px|Starting the resource manager]] To communicate with the VMEbus via the MXI interface, we need to install some drivers. The NI-VXI/VISA drivers include a Resource Manager, an interactive configuration and troubleshooting program, libraries of software routines for MAX programming. First, switch-on the crate and check the led are lit in the front of the board. Then you start the computer and launch MAX. Shown in Figure I.5 is a screenshot from MAX, displaying how you launch the sub-routine “Resource Manager” (Resman). Tools >> NI-VXI >> VXI Ressource Manager [[Image:3D_treeconfiguration.JPG|thumb|right|250px|Tree configuration]] After five second a tree configuration will appear in Devices and Interfaces and the PCI-MXI-2 card, the MXI-2 bridge and the VME controller appear when the drivers are properly installed. There is a yellow exclamation mark on frame 1 due to the fact that our crate is VME, not VXI. The next step is to add the TPLL board in this architecture. Right click on Frame 1 and click on “Create new VME device”. A new window appears and by following the steps the device is installed. The first step is to choose the pseudo logical address to “256”. The logical address distinguishes between all the boards in the crate. Next it is important to select Frame 1 in order to see TPLL in the same frame as the controller. In the next window we can choose either a new device or one already existing (Choose new device). The third step we enter a board name and a manufacturer. The final step is to allocate free memory resources for the device . For TPLL, we must select A32 address range and fill the “Setting” part with the TPLL resource. Currently the range is 0x10000000 – 0x107FFFFF. <gallery caption='Creating a new VME device'> Image:3D_createnewvmedevice.JPG|Create new VME device Image:3D_entervmeparameters1.JPG|Enter parameters Image:3D_entervmeparameters2.JPG|Enter parameters </gallery> At the end of this operation, the VME crate should be operational with the two boards inside and it should appear in the tree architecture. Each device should have a correct resource memory. We can find all this information in the folder “3D Syst VME-MXI-2” on the desktop along with all the National instrument datasheets. If the system needs another board (for example: cooling system), follow the same procedure to add it, but be careful to change pseudo logical address and address range (A32 0x1000…) <center>[[Image:3D_finalvmestructure.JPG|frame|200px|Final VME structure]]</center> ===TPCC board=== [[Image:3D_tpccboard.JPG|thumb|right|250px|Turbo Pixel Control Card]] Now we are ready to plug the multicolor flat cable between the TPLL and the TPCC board. This bridge transfers the data to the TPLL which convert it to be transmitted on the VMEbus. Contrary to the TPLL board which is supplied through the VME crate, the TPCC card need four different power supplies, two digitals and two analogues. These supply the board and a part of the Front end electronic card. Two shielded cables with Molex connectors should be used. The figures show the two connectors plugged in TPCC. The TPCC power cable supplies the TPCC board; it is connected near the multicolor ribbon cable. The FE power connector is plugged on the TPCC back and supplies the Front end card. Be careful with the power, both voltage and current is very important to check and respect the voltage. [[Image:3D_tpccpower2.JPG|thumb|right|250px|Power connector on the TPCC board]] [[Image:3D_fepower3.JPG|thumb|right|250px|Power connector for the FE on the TPCC board]] Pinning on the TPCC connector: #GND VDDD #GND VDDA #VDDD -5V, 0.5A #VDDA +5V, 1.6A Pinning on the FE connector on the TPCC: #GND VDDD #GND VDDA #VDDD +2V, 65mA #VDDA +1.6V, 30mA You can identify pin 1 on the TPCC with the small yellow dot behind the connector close to one leg. The pictures look at the connectors on the TPCC board with the retention nose pointing upwards (flip the board for the FE power). ===Front End electronic card=== The 3D pixel sensor is connected to the FE readout electronic using a complex soldering technique called “Bump bonding”. It needs a great accuracy; each pixel must be connected to each FE readout plot. Such a system is located in Bonn and the 3D sensors from SINTEF are bump bonded there. The electronic board where the 3D detector is bump bonded contains tunable components in order to select the best parameter for each pixel. The 3D sensor is in the middle of the card. At the left there is the high voltage supply to deplete the sensor. To the right, there are the ribbon cable connection to plug this from the TPCC and a LEMO cable. The calibration signal goes through the LEMO cable from the TPCC. We have to be careful with the high voltage applied. The value depends on the pixel sensor type but it is always negative. For example to deplete a 3D pixel detector we supply around -30 volt instead of more than -100 volt for a 2D pixel sensor. So we add voltmeter in parallel to check this voltage. ==Turbo DAQ== II. TurboDAQ The software TurboDAQ is installed on the computer. Currently the release 6.6 is running and all the instructions to download and to install this software are given on the Web page: [http://pixdata.lbl.gov/html/TurboDAQ.htm http://pixdata.lbl.gov/html/TurboDAQ.htm] This software permits to control the data acquisition and display the readout from the pixel detector. It is written in CVI language, so we need the software LabWindows CVI from NI. Currently the release 8.5 of CVI is installed on the computer. All the files concerning the software are in the folder named TurboDAQ on the desktop of the computer. ===TurboDAQ start=== To launch the program double click on the shortcut “TurboDAQ.exe” on desktop. The TurboDAQ main panel comes up. This panel contains all the functions that we can use with this software, but in the case of pixel sensor measurement we do not use all the tabs. Below we will describe the functions and explain the procedure used to carry out measurements. After switching on the VME crate and the computer, “resman” needs to be launched to configure the VME bus. If "resman" is not run, TurboDAQ will crash during initialisation. After that we can start TurboDAQ. The TPCC can be powered either by an independent power supply or with a GPIB power supply linked to the computer. In the first case we adjust the voltage and current button by hand and on the second case we can open the Power console panel in TurboDAQ to tune which supply we want. In both case six LEDs near the supply connector number 1 must light and two others above the multicolor flat cable. If the TPCC LEDs are correctly switched on, we open the Initialise PLL&PCC panel and push the button “Reinitialise”. If all the supply and configuration are correct, we will observe the two lights on the right shutting down and a new orange LED switching on near the FE flat cable. When this is all correct, start fitting the other panels with the necessary parameters. First, open “Configuration” in order to define the parameters of the measurement. Enter the assembly type and the name of the module in “Module identifier”. In case of 3D pixel single chip used, unchanged “PCC/PICT”, “Strobe setup” and “Trigger setup” values. Then select F for the “Global Address” (GA) and fill a value for each parameter. A good idea is to modify them one by one and make a scan to understand their effect. After this, we can start all the three tests at the bottom of the panel, “Send module configuration”, “Test global registers” and “Test pixel registers”. The red light in the right corner must shut down and the black light must become green, else there is problem and an error message will appear. Concerning the temperature, the new TPCC board should show the correct value. We can fill TDACS and FDACS parameters with an already complete file by a previous scan if you click on the white square just below but we will see later in this report. <gallery caption='TurboDAQ screenshots'> Image:3D_turbodaq_initialisation.JPG|Initialisation panel Image:3D_turbodaq_configuration.JPG|Configuration panel Image:3D_turbodaq_datacontrol.JPG|Control panel Image:3D_turbodaq_datafitting.JPG|Datafitting panel Image:3D_turbodaq_scancontrol.JPG|Scancontrol panel Image:3D_turbodaq_onlineplot.JPG|Onlineplot panel </gallery> ===TurboDAQ threshold calibration procedure=== Before used radioactive source to send particle on the detector, we have to calibrate it. Indeed, each pixel must be tune to obtain the same threshold on the entire sensor surface, thus the detector will be efficient. By following this procedure the pixels are tuned: # As it is written before, set the parameters and carried out the first “Threshold Scan, Internal-Cal” # Modified the parameters (for example : GDAC) until to obtain the best first Threshold scan, that is to say, mean threshold value the nearest to the target value enter in “Data fitting” # With this parameters run the scan “TDAC Tune, Internal-Cal” to obtain the first TDAC scan and the file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter, by clicking on the white square and upload the file “namefile_tdacs_0.out”. # Carried out the second threshold scan and observe the improvement. # With this changes run the scan “FDAC Tune, Internal-Cal” to obtain the first FDAC scan and the file “namefile_fdacs_0.out”. # In “Configuration panel” set FDAC parameter, by clicking on the white square and upload the file “namefile_fdacs_0.out”. # Carried out the third threshold scan and observe the improvement. # With this changes run one more scan “TDAC Tune, Internal-Cal” to obtain the second TDAC scan and the second file “namefile_tdacs_0.out”. # In “Configuration panel” set TDAC parameter one more time, by clicking on the white square and upload the second file “namefile_tdacs_0.out”. # Carried out the fourth threshold scan, we should obtain an uniform pixel map. Check the threshold mean value and the noise in the file “namefile_logfile” # Under “Configuration panel” click on “Module configurations”, fill Channel 0 with a name and save the configuration. Now we can use this configuration each time we use the FE with the detector bump bonded on it. We have to carry out this procedure each time we study a new detector system. ==3D sensor types== [[Image:3D_sensortypes.JPG|thumb|center|400px|Different types of 3D sensors]] ==What if TurboDAQ crashes during "initialization"?== Make sure you have run "resman" before starting TurboDAQ. [[User:Dfe002|Dominik]] 09:03, 12 March 2009 (CET) 0d7854173784dbe1ef1cd14132743347008a64ee 2 145 307 2009-03-10T15:19:56Z Tbu082 19 New page: Alex Kastanas userpage wikitext text/x-wiki Alex Kastanas userpage b67ba3a6da482d489a2aa9538c6af8dd01a8ec7d 0 137 308 2009-03-10T15:30:54Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) dd729dc7968f14b854cc446545de957a22381892 309 2009-03-10T15:32:43Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasNordugrid|Nordugrid]] === Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) 67fb3b7a4208e7622174762d941d76f219d3c9c9 314 2009-03-10T15:50:14Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasNordugrid|Nordugrid]] === === [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] === Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) e3aaa3a3ddd8d6255d9c19fde9e2312b5b5cb37a 317 2009-03-10T16:06:29Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasNordugrid|Nordugrid]] === === [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] === === [[AtlasSafety|Safety training for ATLAS work]] === Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) 86e32806ff1bd050fb1899d7c32aa1817e4a29b3 323 2009-03-10T16:32:31Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasNordugrid|Nordugrid]] === === [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) ca5df0ef00cde46af18fddbe0242278bba603c4c 338 2009-03-11T11:58:33Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasNordugrid|Nordugrid]] === === [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] === Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) f9154f0c511b571932c08cd1e23c2a59e9214a71 342 2009-03-11T12:43:31Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasNordugrid|Nordugrid]] === === [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] === === [[AtlasDataFormats| ATLAS data formats]] === Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) 121e1348d5670987c02cad833d474aa27c0830d0 344 2009-03-11T13:16:33Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) 52b5ac81981db75dc7c1cc6b3218856299695c60 345 2009-03-11T13:17:52Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) 6e290d09f00f030a9f0412026f1051dd36cb37e4 346 2009-03-11T13:18:06Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) 7ae8e443b6b626c98cd9173156e82b5ab48eb299 347 2009-03-11T13:19:34Z Kka054 24 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) edff07c34113340490f38dfc47ec0814d2f505eb 0 147 315 2009-03-10T16:03:19Z Kka054 24 New page: = Walkthrough: Setting up ATHENA on a central managed computers = The purpose of this walk through is to create a working *ATHENA* setup on the scratch disk of one of the centrally manage... wikitext text/x-wiki = Walkthrough: Setting up ATHENA on a central managed computers = The purpose of this walk through is to create a working *ATHENA* setup on the scratch disk of one of the centrally managed *Fedora 8* machines. This walk through works successfully on on my desktop machine '''iftsub041012'''. I've assumed you are using '''bash''', if you're using '''csh''', change '''*.sh''' to '''*.csh''', and all variable definitions from <tt>export A=b</tt> to <tt>set A b</tt>. If you are not using a Fedora 8 machine, things may not work. In the case of using a '''Scientific Linux 4''' machine, you can skip the legacy compiler step and the <tt>--pretend-platform</tt> flag to <tt>pacman</tt>. == Installing ATHENA == The '''ATLAS''' offline software '''ATHENA''' can be installed by following the steps described in this section. For your convenience the steps are also implemented in the following script [%ATTACHURL%/setup_install.sh setup_install.sh] === Decide on a version to use and set up directories === The latest stable version of '''ATHENA''' when writing this was <tt>13.0.40</tt>. You'll need a writable directory on a disk with lots of available space to install (~6.5 Gb), for this an external disk or the <tt>/scratch</tt> partition is very useful. To simplify things declare some environment variables and create the directory <pre> export VERSION=13.0.40 export BASEDIR=/scratch/ATLAS export INSTALL=${BASEDIR}/ATLAS_${VERSION} mkdir -p ${INSTALL} </pre> === Legacy compilers === '''Fedora 8''' is '''''almost''''' compatible with '''slc4''' if you use the _legacy compilers_ <tt>gcc34</tt> and <tt>g++34</tt> (gcc 3.4.6) instead of the default compilers <tt>gcc</tt> and <tt>g++</tt> (gcc 4.1.2). To do this place links in to the legacy compilers named as the default compilers in front of your path <pre> mkdir -p ${INSTALL}/mybin cd ${INSTALL}/mybin ln -s /usr/bin/g++34/g++ ln -s /usr/bin/gcc34/gcc export PATH=${INSTALL}/mybin/:$PATH </pre> === Install and run <tt>pacman</tt> === <tt>pacman</tt> is a package installer available from http://physics.bu.edu/pacman/ . Install it by running <pre> cd ${INSTALL} wget http://physics.bu.edu/pacman/sample_cache/tarballs/pacman-latest.tar.gz tar xfvz pacman-latest.tar.gz </pre> To install run <pre> cd ${INSTALL}/pacman-* source setup.sh cd ${INSTALL} VERSION_=`echo ${VERSION} | sed 's,\.,_,g'` pacman -allow trust-all-caches -pretend-platform SLC-4 -V -get am-CERN:AtlasOffline_${VERSION_}_i686_slc4_gcc34_opt </pre> answer '''yall''' to say yes to all questions (safe for a fresh install). Note: '''''Installing ATHENA takes a while (even with a fast internet connection)''''' == Creating a workarea to work on == A workarea using the ATHENA installation can be created by the steps in this section For your convenience the steps are also implemented in the following script [[%ATTACHURL%/setup_workarea.sh][setup_workarea.sh]] === Prepare environment === First set environment variables and create a workarea directory <pre> export VERSION=13.0.40 export BASE=/scratch/ATLAS export WORKAREA=${BASE}/workarea_${VERSION} export INSTALL=${BASE}/ATLAS_${VERSION} export PATH=${INSTALL}/mybin:${PATH} mkdir -p ${WORKAREA} </pre> === Create a requirements file === The '''requirements''' file is used by <tt>cmt</tt>, it must have the path <tt>$WORKAREA/requirements</tt>. The following file was adapted from https://twiki.cern.ch/twiki/bin/view/Atlas/WorkBookSetAccount (note that <tt>SITEROOT</tt> should match your <tt>$INSTALL</tt> directory) <pre> set CMTSITE STANDALONE set SITEROOT /scratch/ATLAS/ macro ATLAS_TEST_AREA /scratch/workarea macro ATLAS_DIST_AREA ${SITEROOT} apply_tag projectArea macro SITE_PROJECT_AREA ${SITEROOT} macro EXTERNAL_PROJECT_AREA ${SITEROOT} apply_tag opt apply_tag setup apply_tag simpleTest use AtlasLogin AtlasLogin-* $(ATLAS_DIST_AREA) set CMTCONFIG i686-slc4-gcc34-opt </pre> It is important to get <tt>set SITEROOT /scratch/ATLAS/</tt> and <tt>macro ATLAS_TEST_AREA /scratch/workarea</tt> to point to your ATLAS software installation and workarea correct. === Prepare workspace === Use '''CMT''' to prepare for running <pre> cd /scratch/workarea source /scratch/ATLAS/CMT/*/mgr/setup.sh cmt config . setup.sh -tag=$VERSION mkdir $VERSION </pre> once this is done, you can run the <tt>root</tt> bundled with the production packages directly from the prompt. You have to initialize the environment before each use, to make things easier create a script <tt>mysetup.sh</tt> that does all the steps for you <pre> export VERSION=13.0.40 export BASE=/scratch/ATLAS export WORKAREA=${BASE}/workarea_${VERSION} export INSTALL=${BASE}/ATLAS_${VERSION} source setup.sh -tag=${VERSION} export PATH=${INSTALL}/mybin:${PATH} </pre> and before using your environment just do <tt>source mysetup.sh</tt> == Adding packages to workspace == How to install packages is also described in the wiki page GettingStartedWithAthena, remeber to source to <tt>/scratch/workarea/mysetup.sh</tt> before compiling! Packages are availible in the cvs http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline/ Make sure that the version of the packages you download are compatible with your ATHENA release! Add the cvs sub-directory to the workspace and unpack downloaded tar-ball there <pre> mkdir -p ${WORKAREA}/${VERSION}/SubDirectory cd mkdir ${WORKAREA}/${VERSION}/SubDirectory #download package here tar xfvz Package.tar.gz </pre> it is not safe to remove the tar-ball. Next configure and build package <pre> cd Package/cmt cmt config source setup.sh gmake </pre> === Adding SUSYDPDMaker to your workarea === These instructions are based on text found on the twiki page https://twiki.cern.ch/twiki/bin/view/Atlas/SusyDPDMaker and requires ATHENA 13.0.40 release to work. Before running remember to do <tt>source mysetup.sh</tt> in your workspace. Make sure you have the <tt>PhysicsAnalysis</tt> directory in your workarea <pre> pa_dir=${WORKAREA}/${VERSION}/PhysicsAnalysis mkdir -p ${pa_dir} </pre> then download unpack and install <tt>DPDUtils-00-00-09</tt> <pre> cd ${pa_dir} wget "http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline/PhysicsAnalysis/DPDUtils.tar.gz?view=tar&pathrev=DPDUtils-00-00-09" tar xfvz DPDUtils.tar.gz* rm DPDUtils.tar.gz* cd DPDUtils/cmt cmt config source setup.sh gmake </pre> and <tt>SUSYPhys/SUSYDPDMaker-00-00-04</tt> <pre> mkdir -p ${pa_dir}/SUSYPhys cd ${pa_dir}/SUSYPhys wget "http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline/PhysicsAnalysis/SUSYPhys/SUSYDPDMaker.tar.gz?view=tar&pathrev=SUSYDPDMaker-00-00-04" tar xfvz SUSYDPDMaker.tar.gz* rm SUSYDPDMaker.tar.gz* cd SUSYDPDMaker/cmt cmt config source setup.sh gmake </pre> fb7fcad49c54f3aac343e54c7f1501a4173a21d6 316 2009-03-10T16:04:22Z Kka054 24 wikitext text/x-wiki = Walkthrough: Setting up ATHENA on a central managed computers = The purpose of this walk through is to create a working *ATHENA* setup on the scratch disk of one of the centrally managed *Fedora 8* machines. This walk through works successfully on on my desktop machine '''iftsub041012'''. I've assumed you are using '''bash''', if you're using '''csh''', change '''*.sh''' to '''*.csh''', and all variable definitions from <tt>export A=b</tt> to <tt>set A b</tt>. If you are not using a Fedora 8 machine, things may not work. In the case of using a '''Scientific Linux 4''' machine, you can skip the legacy compiler step and the <tt>--pretend-platform</tt> flag to <tt>pacman</tt>. == Installing ATHENA == The '''ATLAS''' offline software '''ATHENA''' can be installed by following the steps described in this section. For your convenience the steps are also implemented in the following script [%ATTACHURL%/setup_install.sh setup_install.sh] === Decide on a version to use and set up directories === The latest stable version of '''ATHENA''' when writing this was <tt>13.0.40</tt>. You'll need a writable directory on a disk with lots of available space to install (~6.5 Gb), for this an external disk or the <tt>/scratch</tt> partition is very useful. To simplify things declare some environment variables and create the directory <pre> export VERSION=13.0.40 export BASEDIR=/scratch/ATLAS export INSTALL=${BASEDIR}/ATLAS_${VERSION} mkdir -p ${INSTALL} </pre> === Legacy compilers === '''Fedora 8''' is '''''almost''''' compatible with '''slc4''' if you use the _legacy compilers_ <tt>gcc34</tt> and <tt>g++34</tt> (gcc 3.4.6) instead of the default compilers <tt>gcc</tt> and <tt>g++</tt> (gcc 4.1.2). To do this place links in to the legacy compilers named as the default compilers in front of your path <pre> mkdir -p ${INSTALL}/mybin cd ${INSTALL}/mybin ln -s /usr/bin/g++34/g++ ln -s /usr/bin/gcc34/gcc export PATH=${INSTALL}/mybin/:$PATH </pre> === Install and run <tt>pacman</tt> === <tt>pacman</tt> is a package installer available from http://physics.bu.edu/pacman/ . Install it by running <pre> cd ${INSTALL} wget http://physics.bu.edu/pacman/sample_cache/tarballs/pacman-latest.tar.gz tar xfvz pacman-latest.tar.gz </pre> To install run <pre> cd ${INSTALL}/pacman-* source setup.sh cd ${INSTALL} VERSION_=`echo ${VERSION} | sed 's,\.,_,g'` pacman -allow trust-all-caches -pretend-platform SLC-4 -V -get am-CERN:AtlasOffline_${VERSION_}_i686_slc4_gcc34_opt </pre> answer '''yall''' to say yes to all questions (safe for a fresh install). Note: '''''Installing ATHENA takes a while (even with a fast internet connection)''''' == Creating a workarea to work on == A workarea using the ATHENA installation can be created by the steps in this section For your convenience the steps are also implemented in the following script [[%ATTACHURL%/setup_workarea.sh][setup_workarea.sh]] === Prepare environment === First set environment variables and create a workarea directory <pre> export VERSION=13.0.40 export BASE=/scratch/ATLAS export WORKAREA=${BASE}/workarea_${VERSION} export INSTALL=${BASE}/ATLAS_${VERSION} export PATH=${INSTALL}/mybin:${PATH} mkdir -p ${WORKAREA} </pre> === Create a requirements file === The '''requirements''' file is used by <tt>cmt</tt>, it must have the path <tt>$WORKAREA/requirements</tt>. The following file was adapted from https://twiki.cern.ch/twiki/bin/view/Atlas/WorkBookSetAccount (note that <tt>SITEROOT</tt> should match your <tt>$INSTALL</tt> directory) <pre> set CMTSITE STANDALONE set SITEROOT /scratch/ATLAS/ macro ATLAS_TEST_AREA /scratch/workarea macro ATLAS_DIST_AREA ${SITEROOT} apply_tag projectArea macro SITE_PROJECT_AREA ${SITEROOT} macro EXTERNAL_PROJECT_AREA ${SITEROOT} apply_tag opt apply_tag setup apply_tag simpleTest use AtlasLogin AtlasLogin-* $(ATLAS_DIST_AREA) set CMTCONFIG i686-slc4-gcc34-opt </pre> It is important to get <tt>set SITEROOT /scratch/ATLAS/</tt> and <tt>macro ATLAS_TEST_AREA /scratch/workarea</tt> to point to your ATLAS software installation and workarea correct. === Prepare workspace === Use '''CMT''' to prepare for running <pre> cd /scratch/workarea source /scratch/ATLAS/CMT/*/mgr/setup.sh cmt config . setup.sh -tag=$VERSION mkdir $VERSION </pre> once this is done, you can run the <tt>root</tt> bundled with the production packages directly from the prompt. You have to initialize the environment before each use, to make things easier create a script <tt>mysetup.sh</tt> that does all the steps for you <pre> export VERSION=13.0.40 export BASE=/scratch/ATLAS export WORKAREA=${BASE}/workarea_${VERSION} export INSTALL=${BASE}/ATLAS_${VERSION} source setup.sh -tag=${VERSION} export PATH=${INSTALL}/mybin:${PATH} </pre> and before using your environment just do <tt>source mysetup.sh</tt> == Adding packages to workspace == How to install packages is also described in the wiki page GettingStartedWithAthena, remeber to source to <tt>/scratch/workarea/mysetup.sh</tt> before compiling! Packages are availible in the cvs http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline/ Make sure that the version of the packages you download are compatible with your ATHENA release! Add the cvs sub-directory to the workspace and unpack downloaded tar-ball there <pre> mkdir -p ${WORKAREA}/${VERSION}/SubDirectory cd mkdir ${WORKAREA}/${VERSION}/SubDirectory #download package here tar xfvz Package.tar.gz </pre> it is not safe to remove the tar-ball. Next configure and build package <pre> cd Package/cmt cmt config source setup.sh gmake </pre> === Adding SUSYDPDMaker to your workarea === These instructions are based on text found on the twiki page https://twiki.cern.ch/twiki/bin/view/AtlasProtected/SusyDPDMaker and requires ATHENA 13.0.40 release to work. Before running remember to do <tt>source mysetup.sh</tt> in your workspace. Make sure you have the <tt>PhysicsAnalysis</tt> directory in your workarea <pre> pa_dir=${WORKAREA}/${VERSION}/PhysicsAnalysis mkdir -p ${pa_dir} </pre> then download unpack and install <tt>DPDUtils-00-00-09</tt> <pre> cd ${pa_dir} wget "http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline/PhysicsAnalysis/DPDUtils.tar.gz?view=tar&pathrev=DPDUtils-00-00-09" tar xfvz DPDUtils.tar.gz* rm DPDUtils.tar.gz* cd DPDUtils/cmt cmt config source setup.sh gmake </pre> and <tt>SUSYPhys/SUSYDPDMaker-00-00-04</tt> <pre> mkdir -p ${pa_dir}/SUSYPhys cd ${pa_dir}/SUSYPhys wget "http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline/PhysicsAnalysis/SUSYPhys/SUSYDPDMaker.tar.gz?view=tar&pathrev=SUSYDPDMaker-00-00-04" tar xfvz SUSYDPDMaker.tar.gz* rm SUSYDPDMaker.tar.gz* cd SUSYDPDMaker/cmt cmt config source setup.sh gmake </pre> cbae0bdbea7c64f208cf2a2fa94373340e234e56 6 150 327 2009-03-10T16:39:39Z Kka054 24 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 151 339 2009-03-11T12:37:32Z Kka054 24 New page: %META:TOPICINFO{author="ThomasBurgess" date="1209575726" format="1.1" reprev="1.2" version="1.2"}% %META:TOPICPARENT{name="WebHome"}% %TOC% == Walkthrough: ATLAS simulation using the CSC ... wikitext text/x-wiki %META:TOPICINFO{author="ThomasBurgess" date="1209575726" format="1.1" reprev="1.2" version="1.2"}% %META:TOPICPARENT{name="WebHome"}% %TOC% == Walkthrough: ATLAS simulation using the CSC scripts == If you follow the AthenaKlientDriftWalkThrough you can run the examples in this guide. Various file types of are mentioned in this text: ;'''Ntuple''' :flat ntuples (usable directly in =root=) ;'''RDO''' '''''Raw Data Object''''' :What comes out of the simulation ;'''ESD''' '''''Event Summary Data''''' :Reconstructed '''RDO''' file, used to make '''AOD''' and for ;'''AOD''' '''''Analysis Object Data''''' :Summary of an ''''ESD''' file ;'''DPD''' '''''Derived Physics Data''''' :Analysis specific processed '''AOD''' In general the files are <tt>root</tt> files, but not directly usable in <tt>root</tt>. === Event generation === To generate events use the script <tt>csc_evgen_trf.py</tt> that generates events for a physics process defined in one of the <tt>jobOptions</tt> files located in <tt>$INSTALL/AtlasOffline/13.0.40/Generators/EvgenJobOptions/share</tt>. The script takes the following arguments #<tt>runNumber</tt> (int) #*each run number corresponds to one physics process #<tt>firstEvent</tt> (int) #*number of the first event in the output data file #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>randomSeed</tt> (int) #*random seed for physics generators #<tt>jobConfig</tt> (list) #*<tt>jobOptions</tt> fragment containing the physics and the configuration settings #<tt>outputEvgenFile</tt> (str) #*Output file that contains generated events #[ <tt>histogramFile</tt> ] (str) default='NONE' #*Output file that contains histograms. #[ <tt>ntupleFile</tt> ] (str) default='NONE' #*Output file that contains ntuples. #[ <tt>inputGeneratorFile</tt> ] (str) default='NONE' #*Input file used by the particle generator to generate events The following call generates a run with '''5000''' events for the process '''Z->tau,tau''' and will save the file <tt>005188.evgen.pool.root</tt>. <pre> csc_evgen_trf.py\ 005188 1 5000 1231243\ 'CSC.005188.A3_Ztautau_filter.py'\ '005188.evgen.pool.root' </pre> Note that the run-number must match the =jobOptions= file given. === <tt>Atlfast</tt> '''AOD''' generation === The script <tt>csc_atlfast_trf.py</tt> truns <tt>Atlfast</tt> and produces '''AOD'''s directly from the generated events. It takes the following arguments #<tt>inputEvgenFile</tt> (list) #*Input file that contains generated events #<tt>outputAODFile</tt> (str) #*Output file that contains '''AOD'''s #<tt>ntupleFile</tt> (str) #*Output file that contains ntuples. #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip To run on the file with generated events from the previous section run <pre> csc_atlfast_trf.py\ '005188.evgen.pool.root'\ '005188.atlfast.aod.pool.root'\ '005188.atlfast.nt.root'\ -1 0 </pre> The '''-1''' includes all events in the input file ==== Script that makes several runs of atlfast aod ==== The following <tt>bash</tt> script generates '''nruns''' of '''nevts''' events of the type specified in ''''jobops'''. <pre> nruns=10 nevts="10000" run="005188" jobops=CSC.005188.A3_Ztautau_filter.py for (( i=0; i<nruns; ++i)); do evgen=${nevts}.${i}.${run}.evgen.pool.root atlfast_aod=`echo ${evgen} | sed 's,evgen,atlfast.aod,'` atlfast_nt=`echo ${evgen} | sed 's,evgen,atlfast.nt,'` csc_evgen_trf.py ${run} 1 ${nevts} ${RANDOM} ${jobops} ${evgen} csc_atlfast_trf.py ${evgen} ${atlfast_aod} ${atlfast_nt} -1 0 done </pre> === Making '''ESD'''s '''AOD'''s using full ATLAS simulation === In these examples use the geometry definition <tt>ATLAS-CSC-01-02-00</tt> and the DEFAULT trigger. Remember that the '''Geant4''' step is very slow, run in a few events only until you know what you are doing. ==== '''GEANT4''' simulation and digitization ==== The script <tt>csc_simul_trf.py</tt> runs the '''GEANT4''' and digitization on the generated events and produces a '''HITS''' and a '''RDO''' file. It has the following options #<tt>inputEvgenFile</tt> (list) #*Input file that contains generated events #<tt>outputHitsFile</tt> (str) #*Output file that contains hits #<tt>outputRDOFile</tt> (str) #*Output file that contains RDO's #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>randomSeed</tt> (int) #*random seed for simulation #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>digiSeedOffset1</tt> (int) #*random seed offset for digitization #<tt>digiSeedOffset2</tt> (int) #*random seed offset for digitization #[ <tt>physicsList</tt> ] (str) default='QGSP_EMV' #*physics list to be used #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: .,SimuJobTransforms,PyJobTransforms #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use #[ <tt>triggerConfig</tt> ] (str) default='DEFAULT' #*Configuration string to use for =TrigT1= and =HLT=. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. Run the full detector simulation: <pre> csc_simul_trf.py\ '005188.evgen.pool.root'\ '005188.hits.pool.root'\ '005188.rdo.pool.root'\ -1 0 123\ 'ATLAS-CSC-01-02-00'\ 12 23 </pre> ==== Reconstruction - create an '''ESD''' ==== The reconstruction can be run using the following script <tt>csc_recoESD_trf.py</tt> which takes the '''RDO''' file from the simulation and produces an '''ESD''' file. The scripts has the following options #<tt>inputRDOFile</tt> (list) #*Input file that contains RDOs #<tt>outputESDFile</tt> (str) #*Output file that contains ESDs #<tt>ntupleFile</tt> (str) #*Output file that contains ntuples. #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>triggerConfig</tt> (str) #*Configuration string to use for <tt>TrigT1</tt> and <tt>HLT</tt>. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: RecJobTransforms, PyJobTransforms #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use To run on the simulated '''RDO''' file run <pre> csc_recoESD_trf.py\ '005188.rdo.pool.root'\ '005188.esd.pool.root'\ '005188.rdo.ntuple.pool.root'\ -1 0\ 'ATLAS-CSC-01-02-00'\ 'DEFAULT' </pre> ==== Create '''AOD''' from an '''ESD''' ==== The script <tt>csc_recoAOD_trf.py</tt> makes an '''AOD''' file from an '''ESD''' file. #<tt>inputESDFile</tt> (list) #*Input file that contains ESDs #<tt>outputAODFile</tt> (str) #*Output file that contains AODs #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>triggerConfig</tt> (str) #*Configuration string to use for <tt>TrigT1</tt> and <tt>HLT</tt>. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: <tt>RecJobTransforms</tt> , <tt>PyJobTransforms</tt> #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use Run like this <pre> csc_recoAOD_trf.py\ '005188.esd.pool.root'\ '005188.aod.pool.root'\ -1 0\ 'ATLAS-CSC-01-02-00'\ 'DEFAULT' </pre> [[User:Kka054|Kka054]] 13:37, 11 March 2009 (CET) d212954d4f749fe47e95645250c1e26553e6c7d0 340 2009-03-11T12:37:49Z Kka054 24 wikitext text/x-wiki == Walkthrough: ATLAS simulation using the CSC scripts == If you follow the AthenaKlientDriftWalkThrough you can run the examples in this guide. Various file types of are mentioned in this text: ;'''Ntuple''' :flat ntuples (usable directly in =root=) ;'''RDO''' '''''Raw Data Object''''' :What comes out of the simulation ;'''ESD''' '''''Event Summary Data''''' :Reconstructed '''RDO''' file, used to make '''AOD''' and for ;'''AOD''' '''''Analysis Object Data''''' :Summary of an ''''ESD''' file ;'''DPD''' '''''Derived Physics Data''''' :Analysis specific processed '''AOD''' In general the files are <tt>root</tt> files, but not directly usable in <tt>root</tt>. === Event generation === To generate events use the script <tt>csc_evgen_trf.py</tt> that generates events for a physics process defined in one of the <tt>jobOptions</tt> files located in <tt>$INSTALL/AtlasOffline/13.0.40/Generators/EvgenJobOptions/share</tt>. The script takes the following arguments #<tt>runNumber</tt> (int) #*each run number corresponds to one physics process #<tt>firstEvent</tt> (int) #*number of the first event in the output data file #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>randomSeed</tt> (int) #*random seed for physics generators #<tt>jobConfig</tt> (list) #*<tt>jobOptions</tt> fragment containing the physics and the configuration settings #<tt>outputEvgenFile</tt> (str) #*Output file that contains generated events #[ <tt>histogramFile</tt> ] (str) default='NONE' #*Output file that contains histograms. #[ <tt>ntupleFile</tt> ] (str) default='NONE' #*Output file that contains ntuples. #[ <tt>inputGeneratorFile</tt> ] (str) default='NONE' #*Input file used by the particle generator to generate events The following call generates a run with '''5000''' events for the process '''Z->tau,tau''' and will save the file <tt>005188.evgen.pool.root</tt>. <pre> csc_evgen_trf.py\ 005188 1 5000 1231243\ 'CSC.005188.A3_Ztautau_filter.py'\ '005188.evgen.pool.root' </pre> Note that the run-number must match the =jobOptions= file given. === <tt>Atlfast</tt> '''AOD''' generation === The script <tt>csc_atlfast_trf.py</tt> truns <tt>Atlfast</tt> and produces '''AOD'''s directly from the generated events. It takes the following arguments #<tt>inputEvgenFile</tt> (list) #*Input file that contains generated events #<tt>outputAODFile</tt> (str) #*Output file that contains '''AOD'''s #<tt>ntupleFile</tt> (str) #*Output file that contains ntuples. #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip To run on the file with generated events from the previous section run <pre> csc_atlfast_trf.py\ '005188.evgen.pool.root'\ '005188.atlfast.aod.pool.root'\ '005188.atlfast.nt.root'\ -1 0 </pre> The '''-1''' includes all events in the input file ==== Script that makes several runs of atlfast aod ==== The following <tt>bash</tt> script generates '''nruns''' of '''nevts''' events of the type specified in ''''jobops'''. <pre> nruns=10 nevts="10000" run="005188" jobops=CSC.005188.A3_Ztautau_filter.py for (( i=0; i<nruns; ++i)); do evgen=${nevts}.${i}.${run}.evgen.pool.root atlfast_aod=`echo ${evgen} | sed 's,evgen,atlfast.aod,'` atlfast_nt=`echo ${evgen} | sed 's,evgen,atlfast.nt,'` csc_evgen_trf.py ${run} 1 ${nevts} ${RANDOM} ${jobops} ${evgen} csc_atlfast_trf.py ${evgen} ${atlfast_aod} ${atlfast_nt} -1 0 done </pre> === Making '''ESD'''s '''AOD'''s using full ATLAS simulation === In these examples use the geometry definition <tt>ATLAS-CSC-01-02-00</tt> and the DEFAULT trigger. Remember that the '''Geant4''' step is very slow, run in a few events only until you know what you are doing. ==== '''GEANT4''' simulation and digitization ==== The script <tt>csc_simul_trf.py</tt> runs the '''GEANT4''' and digitization on the generated events and produces a '''HITS''' and a '''RDO''' file. It has the following options #<tt>inputEvgenFile</tt> (list) #*Input file that contains generated events #<tt>outputHitsFile</tt> (str) #*Output file that contains hits #<tt>outputRDOFile</tt> (str) #*Output file that contains RDO's #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>randomSeed</tt> (int) #*random seed for simulation #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>digiSeedOffset1</tt> (int) #*random seed offset for digitization #<tt>digiSeedOffset2</tt> (int) #*random seed offset for digitization #[ <tt>physicsList</tt> ] (str) default='QGSP_EMV' #*physics list to be used #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: .,SimuJobTransforms,PyJobTransforms #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use #[ <tt>triggerConfig</tt> ] (str) default='DEFAULT' #*Configuration string to use for =TrigT1= and =HLT=. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. Run the full detector simulation: <pre> csc_simul_trf.py\ '005188.evgen.pool.root'\ '005188.hits.pool.root'\ '005188.rdo.pool.root'\ -1 0 123\ 'ATLAS-CSC-01-02-00'\ 12 23 </pre> ==== Reconstruction - create an '''ESD''' ==== The reconstruction can be run using the following script <tt>csc_recoESD_trf.py</tt> which takes the '''RDO''' file from the simulation and produces an '''ESD''' file. The scripts has the following options #<tt>inputRDOFile</tt> (list) #*Input file that contains RDOs #<tt>outputESDFile</tt> (str) #*Output file that contains ESDs #<tt>ntupleFile</tt> (str) #*Output file that contains ntuples. #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>triggerConfig</tt> (str) #*Configuration string to use for <tt>TrigT1</tt> and <tt>HLT</tt>. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: RecJobTransforms, PyJobTransforms #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use To run on the simulated '''RDO''' file run <pre> csc_recoESD_trf.py\ '005188.rdo.pool.root'\ '005188.esd.pool.root'\ '005188.rdo.ntuple.pool.root'\ -1 0\ 'ATLAS-CSC-01-02-00'\ 'DEFAULT' </pre> ==== Create '''AOD''' from an '''ESD''' ==== The script <tt>csc_recoAOD_trf.py</tt> makes an '''AOD''' file from an '''ESD''' file. #<tt>inputESDFile</tt> (list) #*Input file that contains ESDs #<tt>outputAODFile</tt> (str) #*Output file that contains AODs #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>triggerConfig</tt> (str) #*Configuration string to use for <tt>TrigT1</tt> and <tt>HLT</tt>. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: <tt>RecJobTransforms</tt> , <tt>PyJobTransforms</tt> #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use Run like this <pre> csc_recoAOD_trf.py\ '005188.esd.pool.root'\ '005188.aod.pool.root'\ -1 0\ 'ATLAS-CSC-01-02-00'\ 'DEFAULT' </pre> [[User:Kka054|Kka054]] 13:37, 11 March 2009 (CET) c3fc455a4d388787dab7dee14463643c645ee9ae 341 2009-03-11T12:39:58Z Kka054 24 wikitext text/x-wiki == Walkthrough: ATLAS simulation using the CSC scripts == If you follow the AthenaKlientDriftWalkThrough you can run the examples in this guide. Various file types of are mentioned in this text: ;'''Ntuple''' :flat ntuples (usable directly in =root=) ;'''RDO''' '''''Raw Data Object''''' :What comes out of the simulation ;'''ESD''' '''''Event Summary Data''''' :Reconstructed '''RDO''' file, used to make '''AOD''' and for ;'''AOD''' '''''Analysis Object Data''''' :Summary of an ''''ESD''' file ;'''DPD''' '''''Derived Physics Data''''' :Analysis specific processed '''AOD''' In general the files are <tt>root</tt> files, but not directly usable in <tt>root</tt>. === Event generation === To generate events use the script <tt>csc_evgen_trf.py</tt> that generates events for a physics process defined in one of the <tt>jobOptions</tt> files located in <tt>$INSTALL/AtlasOffline/13.0.40/Generators/EvgenJobOptions/share</tt>. The script takes the following arguments #<tt>runNumber</tt> (int) #*each run number corresponds to one physics process #<tt>firstEvent</tt> (int) #*number of the first event in the output data file #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>randomSeed</tt> (int) #*random seed for physics generators #<tt>jobConfig</tt> (list) #*<tt>jobOptions</tt> fragment containing the physics and the configuration settings #<tt>outputEvgenFile</tt> (str) #*Output file that contains generated events #[ <tt>histogramFile</tt> ] (str) default='NONE' #*Output file that contains histograms. #[ <tt>ntupleFile</tt> ] (str) default='NONE' #*Output file that contains ntuples. #[ <tt>inputGeneratorFile</tt> ] (str) default='NONE' #*Input file used by the particle generator to generate events The following call generates a run with '''5000''' events for the process '''Z->tau,tau''' and will save the file <tt>005188.evgen.pool.root</tt>. <pre> csc_evgen_trf.py\ 005188 1 5000 1231243\ 'CSC.005188.A3_Ztautau_filter.py'\ '005188.evgen.pool.root' </pre> Note that the run-number must match the =jobOptions= file given. === <tt>Atlfast</tt> '''AOD''' generation === The script <tt>csc_atlfast_trf.py</tt> truns <tt>Atlfast</tt> and produces '''AOD'''s directly from the generated events. It takes the following arguments #<tt>inputEvgenFile</tt> (list) #*Input file that contains generated events #<tt>outputAODFile</tt> (str) #*Output file that contains '''AOD'''s #<tt>ntupleFile</tt> (str) #*Output file that contains ntuples. #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip To run on the file with generated events from the previous section run <pre> csc_atlfast_trf.py\ '005188.evgen.pool.root'\ '005188.atlfast.aod.pool.root'\ '005188.atlfast.nt.root'\ -1 0 </pre> The '''-1''' includes all events in the input file ==== Script that makes several runs of atlfast aod ==== The following <tt>bash</tt> script generates '''nruns''' of '''nevts''' events of the type specified in ''''jobops'''. <pre> nruns=10 nevts="10000" run="005188" jobops=CSC.005188.A3_Ztautau_filter.py for (( i=0; i<nruns; ++i)); do evgen=${nevts}.${i}.${run}.evgen.pool.root atlfast_aod=`echo ${evgen} | sed 's,evgen,atlfast.aod,'` atlfast_nt=`echo ${evgen} | sed 's,evgen,atlfast.nt,'` csc_evgen_trf.py ${run} 1 ${nevts} ${RANDOM} ${jobops} ${evgen} csc_atlfast_trf.py ${evgen} ${atlfast_aod} ${atlfast_nt} -1 0 done </pre> === Making '''ESD'''s '''AOD'''s using full ATLAS simulation === In these examples use the geometry definition <tt>ATLAS-CSC-01-02-00</tt> and the DEFAULT trigger. Remember that the '''Geant4''' step is very slow, run in a few events only until you know what you are doing. ==== '''GEANT4''' simulation and digitization ==== The script <tt>csc_simul_trf.py</tt> runs the '''GEANT4''' and digitization on the generated events and produces a '''HITS''' and a '''RDO''' file. It has the following options #<tt>inputEvgenFile</tt> (list) #*Input file that contains generated events #<tt>outputHitsFile</tt> (str) #*Output file that contains hits #<tt>outputRDOFile</tt> (str) #*Output file that contains RDO's #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>randomSeed</tt> (int) #*random seed for simulation #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>digiSeedOffset1</tt> (int) #*random seed offset for digitization #<tt>digiSeedOffset2</tt> (int) #*random seed offset for digitization #[ <tt>physicsList</tt> ] (str) default='QGSP_EMV' #*physics list to be used #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: .,SimuJobTransforms,PyJobTransforms #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use #[ <tt>triggerConfig</tt> ] (str) default='DEFAULT' #*Configuration string to use for =TrigT1= and =HLT=. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. Run the full detector simulation: <pre> csc_simul_trf.py\ '005188.evgen.pool.root'\ '005188.hits.pool.root'\ '005188.rdo.pool.root'\ -1 0 123\ 'ATLAS-CSC-01-02-00'\ 12 23 </pre> ==== Reconstruction - create an '''ESD''' ==== The reconstruction can be run using the following script <tt>csc_recoESD_trf.py</tt> which takes the '''RDO''' file from the simulation and produces an '''ESD''' file. The scripts has the following options #<tt>inputRDOFile</tt> (list) #*Input file that contains RDOs #<tt>outputESDFile</tt> (str) #*Output file that contains ESDs #<tt>ntupleFile</tt> (str) #*Output file that contains ntuples. #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>triggerConfig</tt> (str) #*Configuration string to use for <tt>TrigT1</tt> and <tt>HLT</tt>. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: RecJobTransforms, PyJobTransforms #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use To run on the simulated '''RDO''' file run <pre> csc_recoESD_trf.py\ '005188.rdo.pool.root'\ '005188.esd.pool.root'\ '005188.rdo.ntuple.pool.root'\ -1 0\ 'ATLAS-CSC-01-02-00'\ 'DEFAULT' </pre> ==== Create '''AOD''' from an '''ESD''' ==== The script <tt>csc_recoAOD_trf.py</tt> makes an '''AOD''' file from an '''ESD''' file. #<tt>inputESDFile</tt> (list) #*Input file that contains ESDs #<tt>outputAODFile</tt> (str) #*Output file that contains AODs #<tt>maxEvents</tt> (int) #*Maximum number of events to process #<tt>skipEvents</tt> (int) #*Number of events to skip #<tt>geometryVersion</tt> (str) #*Geometry Version #<tt>triggerConfig</tt> (str) #*Configuration string to use for <tt>TrigT1</tt> and <tt>HLT</tt>. Set to 'NONE' to switch off trigger, and set to 'DEFAULT' to use the default of the used release. #[ <tt>jobConfig</tt> ] (list) default='NONE' #*Joboptions file with user settings, in particular the configuration settings. Default packages: <tt>RecJobTransforms</tt> , <tt>PyJobTransforms</tt> #[ <tt>DBRelease</tt> ] (str) default='NONE' #*Tarball containing the DBRelease to use Run like this <pre> csc_recoAOD_trf.py\ '005188.esd.pool.root'\ '005188.aod.pool.root'\ -1 0\ 'ATLAS-CSC-01-02-00'\ 'DEFAULT' </pre> [[User:Kka054|Kka054]] 13:37, 11 March 2009 (CET) a253d358404649240cc69afe5b9fbce8771ed57a 0 33 350 2009-03-11T13:57:29Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /prog/altera/vhdl/apex20ke [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDl]] [[Category:Mikroelektronikk]] 9a6421a86e76dc945f33c8f799d9904de6c939db 0 36 351 2009-03-11T14:42:29Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 6bf2a8caf0e4dface9db3c7778482ffe7df9502f 352 2009-03-11T14:43:48Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/quartus6.0 </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 0a62e906611e0d6eaaffef47199a8d8e339dd791 354 2009-03-11T14:57:36Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/quartus6.0 </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] dbf73dd0e2fc1bb848f292904bc9ad4558a26247 370 2009-03-15T20:23:21Z St12361 17 Corrected to run properly under QuestaSim v.6.4a wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/quartus6.0 </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 8405e139ca0646030944c4b37a295730c1700fd5 0 23 353 2009-03-11T14:48:56Z Hsa061 18 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, Kristine, ... ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] 4f5b8d7bfa85ad98ea882d5f1eb5920cd13b9616 0 1 355 2009-03-12T07:34:57Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til Institutt for Fysikk og Teknologis Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] ce144a4d73b2dcb4bf9537d3fd7f93fdfc2a277d 368 2009-03-13T07:43:12Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til [http:/www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] d88b2e89420fbb72bacd59498bb428f1bf6337d3 369 2009-03-13T07:43:45Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 68166c48bdaea44d6eed6e617075e6cea17123a6 0 154 356 2009-03-12T07:50:45Z Nfyku 4 New page: IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte ... wikitext text/x-wiki IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte sysops-rettigheter for å kunne opprette eller redigere sider. Noen bruker (Bureaucrats) kan gi slike rettigheter. Ta kontakt med noen av dem hvis du trenger editeringsrettigheter: Dominik Fehlker ---- <references/> 298d05d03e07fbfa4df67461623a7acb54dad698 357 2009-03-12T07:56:20Z Nfyku 4 wikitext text/x-wiki IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte sysops-rettigheter for å kunne opprette eller redigere sider. Noen brukere (Bureaucrats) kan gi slike rettigheter. Ta kontakt med en av dem hvis du trenger editeringsrettigheter. Husk å logge inn før du spør om slike rettigheter. * Dominik Fehlker * Kjetil Ullaland * Nikolai Østgård * Thomas Burgess ---- <references/> 177eb2601aad05a21395738365f438f72a26f5b1 363 2009-03-12T08:05:07Z Nfyku 4 wikitext text/x-wiki IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte sysops-rettigheter for å kunne opprette eller redigere sider. Noen brukere (Bureaucrats) kan gi slike rettigheter. Ta kontakt med en av dem hvis du trenger editeringsrettigheter. Husk å logge inn før du spør om slike rettigheter. * [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] * [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] * [http://www.uib.no/personer/Nikolai.Ostgaard Nikolai Østgaard] * Thomas Burgess ---- <references/> bc5b9e7cb0813e7c49e75c9b715b21bc84720f52 365 2009-03-12T08:34:50Z Nfyku 4 wikitext text/x-wiki IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte sysops-rettigheter for å kunne opprette eller redigere sider. Noen brukere (Bureaucrats) kan gi slike rettigheter. Ta kontakt med en av dem hvis du trenger editeringsrettigheter. Husk å logge inn før du spør om slike rettigheter. * [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] * [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] * [http://www.uib.no/personer/Nikolai.Ostgaard Nikolai Østgaard] * [[User:Tbu082|Thomas Burgess]] ---- <references/> 8ef23bb84f0e7003dc5b11b8c4791301a23c8729 366 2009-03-12T08:50:00Z Nfyku 4 wikitext text/x-wiki IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte sysops-rettigheter for å kunne opprette eller redigere sider. Noen brukere (Bureaucrats) kan gi slike rettigheter. Ta kontakt med en av dem hvis du trenger editeringsrettigheter. Husk å logge inn før du spør om slike rettigheter. * [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] * [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] * [http://www.uib.no/personer/Nikolai.Ostgaard Nikolai Østgaard] * [[User:Tbu082|Thomas Burgess]] ---- <references/> 8de1bc248adf9fe3e34483af4744ad78d655f85b 6 155 358 2009-03-12T07:57:49Z Kka054 24 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 22 362 2009-03-12T08:04:26Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === [[Image:MAPD_radiotracer.JPG‎|frame|right|200px|Fluorodeoxyglucose-FDG]] [[Image:MAPD_positronelectronannihilation.JPG‎‎|frame|left|200px|Positron - Electron Annihilation]] The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === [[Image:MAPD_crystaltransition.JPG‎ |frame|left|200px|Electronic transition in a crystal]] A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === [[Image:MAPD_coincidenceprinciple.JPG‎ |frame|none|200px|Coincidence detection principle]] In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. [[Image:MAPD_coincidencecategories.JPG|frame||200px|3 different coincidence detection events]] * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. [[Image:MAPD tofprinciple.jpg‎ |frame|none|200px|Time of flight principle]] [[Image:MAPD tofprinciple2.JPG|frame|none|200px|Time of flight principle]] == Technology == === Avalanche Photodiodes === [[Image:MAPD structure.jpg‎|frame|right|200px|Structure of MAPD]] An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. [[Image:MAPD proportionalmode.jpg‎ ‎|frame|right|200px|proportional mode]] * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. [[Image:MAPD geigermode.jpg‎‎|frame|right|200px|Geiger mode]] [[Image:MAPD_passivequenching.jpg‎‎|frame|right|200px|passive quenching]] The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. == Characterisation Cell == == Characterisation setup and results == == [[Photomultipliers]] == [[User:Dfe002|Dominik]] 09:04, 12 March 2009 (CET) [[Category:Detector lab]] 69f49c1061d4f8fa0970a08049a5664e3abfadcb 2 156 367 2009-03-12T08:50:23Z Nfyku 4 New page: [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] wikitext text/x-wiki [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] 0af0e2e1effe30899a80d71ce85838af2bb1a172 0 139 371 2009-03-17T10:30:00Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] 3bf432d60fc8fe00d8544978f365ae1af8293649 0 157 372 2009-03-17T10:33:08Z Tbu082 19 New page: == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What i... wikitext text/x-wiki == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using dq2 * Using root in a job * Using athena in a job * Compiling an athena module in a job 158a53477d03c47b315c3edef32a714493b0b00f 373 2009-03-17T10:44:30Z Tbu082 19 wikitext text/x-wiki == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using dq2 * Using root in a job * Using athena in a job * Compiling an athena module in a job == Evo connection information == Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Central European Time 2009-03-18 12:00-15:00 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl - Phone Bridge ID: 863906 Password: 0686 - Switzerland (CERN, Geneva) +41 22 76 71400 f8c9a49bb4e21ec544ee63bb8fa64e23aa2d7a26 0 157 374 2009-03-17T10:50:53Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using dq2 * Using root in a job * Using athena in a job * Compiling an athena module in a job == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Central European Time 2009-03-18 12:00-15:00 Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl - Phone Bridge ID: 863906 Password: 0686 - Switzerland (CERN, Geneva) +41 22 76 71400 f9b83c3382e75e2c2bfd6de6db73e94270b4eb5c 375 2009-03-17T10:54:18Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using dq2 * Using root in a job * Using athena in a job * Compiling an athena module in a job == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> a2b2b78b8c5b66110ea0923d26411a47696fd5ee 377 2009-03-18T11:34:52Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/f/f6/FimmWorkshop18.03.09.pdf == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using dq2 * Using root in a job * Using athena in a job * Compiling an athena module in a job == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> ff4b503b34ecf16cf52290bead8b0a7a9336c981 379 2009-03-18T12:36:31Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/f/f6/FimmWorkshop18.03.09v2.pdf == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using dq2 * Using root in a job * Using athena in a job * Compiling an athena module in a job == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics, Computing]] f8de0310301e4708ce182a8f569759282cca16ad 380 2009-03-18T12:36:49Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/f/f6/FimmWorkshop18.03.09v2.pdf == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using dq2 * Using root in a job * Using athena in a job * Compiling an athena module in a job == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] ddff58ac9a34a63036b4c75c8602a820ae2e6917 381 2009-03-18T12:42:43Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 58e54df201949fc3a004caa991914a725911664b 421 381 2009-04-24T10:45:54Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 1) /work/atlas was broken by some cleaning script! for now use /work2/atlas instead 2) I have removed the old atlas installations, we now use the grid installations * to see what versions are available use sh /work2/atlas/install_scripts/list_athena_release.sh (current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) * to get an athena environment use source /work2/atlas/install_scripts/setup_athena.sh version (where version is one in the previous list) * to get a work area use source /work2/atlas/install_scripts/setup_athena_workarea.sh 3) for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm 4) make sure everyone can see your files, please run the following commands chown -R ${USER}:atlasuib /work/${USER} /work2/${USER} chmod -R g+r /work/${USER} /work2/${USER} and in case you have something in /workX/users/ do the same for these files 5) With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome ssh -X ${USER}@fimm.bccs.uib.no qsub -I -X (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3 source /work2/atlas/install_scripts/setup_athena_workarea.sh and in the prompt run either atlantis or vp1 == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] daf7a348ce5071238120483c2a016bb2007f60b8 423 421 2009-04-24T11:40:43Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre>sh /work2/atlas/install_scripts/list_athena_release.sh (current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) </pre> #* to get an athena environment use <pre> source /work2/atlas/install_scripts/setup_athena.sh version </pre> (where version is one in the previous list) #* to get a work area use <pre> source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre> chown -R ${USER}:atlasuib /work/${USER} /work2/${USER} chmod -R g+r /work/${USER} /work2/${USER} </pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files 5) With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre> ssh -X ${USER}@fimm.bccs.uib.no qsub -I -X </pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre> source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3 source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 4464eb9eaa8a43ef1f7d1750c7e0f66ee086fa51 424 423 2009-04-24T11:41:11Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre> sh /work2/atlas/install_scripts/list_athena_release.sh </pre> (current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) </pre> #* to get an athena environment use <pre> source /work2/atlas/install_scripts/setup_athena.sh version </pre> (where version is one in the previous list) #* to get a work area use <pre> source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre> chown -R ${USER}:atlasuib /work/${USER} /work2/${USER} chmod -R g+r /work/${USER} /work2/${USER} </pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files 5) With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre> ssh -X ${USER}@fimm.bccs.uib.no qsub -I -X </pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre> source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3 source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 4054963508684c93dfc8ef0dce587f45aa730e49 425 424 2009-04-24T11:41:41Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre> sh /work2/atlas/install_scripts/list_athena_release.sh </pre> (current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre> source /work2/atlas/install_scripts/setup_athena.sh version </pre> (where version is one in the previous list) #* to get a work area use <pre> source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre> chown -R ${USER}:atlasuib /work/${USER} /work2/${USER} chmod -R g+r /work/${USER} /work2/${USER} </pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files 5) With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre> ssh -X ${USER}@fimm.bccs.uib.no qsub -I -X </pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre> source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3 source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] fc0cbd37ac99b164559262f461632dbe8d5a5625 426 425 2009-04-24T11:42:47Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use #:<pre> sh /work2/atlas/install_scripts/list_athena_release.sh </pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre> source /work2/atlas/install_scripts/setup_athena.sh version </pre> (where version is one in the previous list) #* to get a work area use <pre> source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre> chown -R ${USER}:atlasuib /work/${USER} /work2/${USER} chmod -R g+r /work/${USER} /work2/${USER} </pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files 5) With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre> ssh -X ${USER}@fimm.bccs.uib.no qsub -I -X </pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre> source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3 source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 6c63115bd44cfa27e21006e073436c07b68f27c2 427 426 2009-04-24T11:43:26Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre>sh /work2/atlas/install_scripts/list_athena_release.sh</pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre> source /work2/atlas/install_scripts/setup_athena.sh version </pre> (where version is one in the previous list) #* to get a work area use <pre> source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre> chown -R ${USER}:atlasuib /work/${USER} /work2/${USER} chmod -R g+r /work/${USER} /work2/${USER} </pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files 5) With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre> ssh -X ${USER}@fimm.bccs.uib.no qsub -I -X </pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre> source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3 source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 56382c439b61494a82382baf37ec5de1488363c0 428 427 2009-04-24T11:44:07Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre>sh /work2/atlas/install_scripts/list_athena_release.sh</pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre>source /work2/atlas/install_scripts/setup_athena.sh version</pre> (where version is one in the previous list) #* to get a work area use <pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands<pre> chown -R ${USER}:atlasuib /work/${USER} /work2/${USER} chmod -R g+r /work/${USER} /work2/${USER}</pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files 5) With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre> ssh -X ${USER}@fimm.bccs.uib.no qsub -I -X </pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre> source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3 source /work2/atlas/install_scripts/setup_athena_workarea.sh </pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] c7e78f0911bf7a84f7cd2b4b6e659d8128506ab9 6 158 376 2009-03-18T11:34:24Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 159 378 2009-03-18T12:35:53Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 137 382 2009-03-18T14:32:43Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[Tutorial]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) 50e59b6ccdd9153e1c9cc6acdd558eb4c01f7f93 383 2009-03-18T14:32:57Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] c0a5d53a51513412b108f0c4eefe124d0e8b5179 384 2009-03-18T14:33:16Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 82d2ad7680c1e660238a0bd8043a6a40828a2b22 385 2009-03-18T14:33:33Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 7fb7ec1846d774e89fca41dbd82616ac813a2604 405 2009-04-12T20:32:38Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] e015551131afecc6ca797b25b4a07ede8df69aa7 0 160 386 2009-03-18T14:39:11Z Tbu082 19 New page: == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collabor... wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial a9e9f3f5e6a6cd3fb3ddc347c78c3652a703162b 387 2009-03-18T14:39:34Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial [[Category:Particle Physics]] 7700228f5c70be161e1b649014eabab07e71d03d 388 2009-03-18T14:42:42Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] 94b1b999c0373370bcc3312a59a1bb0652405c08 389 2009-03-18T14:49:39Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] 0d2ff629e357f368ab924fd3f67b9f443167047e 390 2009-03-18T15:16:04Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class ** Using svn / cvs * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions ** ssh / scp usage * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] 3edd0bad2e3278723d524c6743f7d6fad7775790 416 390 2009-04-24T10:43:19Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[TutorialUpdate]] (relevant changes since the last tutorial) == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class ** Using svn / cvs * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions ** ssh / scp usage * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] e7f0850ae4fe2c2648384501779a034bb577aa23 417 416 2009-04-24T10:43:29Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[TutorialUpdate]] (relevant changes since the last tutorial) == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class ** Using svn / cvs * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions ** ssh / scp usage * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] da817fe122a3447cf97fe1f1b2b33d16e3aaf7c9 418 417 2009-04-24T10:44:06Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] also read the [[TutorialUpdate190309]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class ** Using svn / cvs * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions ** ssh / scp usage * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] 65333ea7f43762fb2908bd02ceea4ea76644177b 422 418 2009-04-24T10:46:15Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class ** Using svn / cvs * Linux/Shell scripting ** Some useful Linux commands *** bc, sed, awk, grep ** Common problems and solutions ** ssh / scp usage * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] b0ace864b678750c9516a5bd61c0de94fbc0f31f 0 21 391 2009-03-19T09:58:45Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The laboratory is situated in the 3rd floor at the IFT, room 332. == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] f57e81118bc1f6d2de5b2d5cc6f7a922dc81beaa 0 36 392 2009-03-20T15:10:32Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/quartus8.1/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). Vi må ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, ellers vil ikkje simuleringa virka. På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi(husk å kompilere i rett rekkefølge med compileorder->autogenerate) filene. ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] dc61c2bd6a143c0e8ddc08275346bbee3114e2d6 393 2009-03-20T15:44:19Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/quartus6.0 </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). ''NB. Kompilatoren feilar hvis vi har beheld entity deklarasjonen i begge filane som skal inkluderast i testbenken. Dette kan vi løyse enten ved å ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, eller ved å fjerne enitity deklarasjonen i den opprinnelige koden.'' ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 10020e8825c668cbac4f90e145be74431836adfb 394 2009-03-20T15:46:42Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å synthisiere vhdl kode. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/quartus6.0 </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). ''NB. Simulatoren feilar hvis vi har beheld entity deklarasjonen i begge filane som skal inkluderast i testbenken. Dette kan vi løyse enten ved å ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, eller ved å fjerne enitity deklarasjonen i den opprinnelige koden.'' ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til add_sub_alu.vho=== <pre> -- Copyright (C) 1991-2005 Altera Corporation -- Any megafunction design, and related netlist (encrypted or decrypted), -- support information, device programming or simulation file, and any other -- associated documentation or information provided by Altera or a partner -- under Altera's Megafunction Partnership Program may be used only -- to program PLD devices (but not masked PLD devices) from Altera. Any -- other use of such megafunction design, netlist, support information, -- device programming or simulation file, or any other related documentation -- or information is prohibited for any other purpose, including, but not -- limited to modification, reverse engineering, de-compiling, or use with -- any other silicon devices, unless such use is explicitly licensed under -- a separate agreement with Altera or a megafunction partner. Title to the -- intellectual property, including patents, copyrights, trademarks, trade -- secrets, or maskworks, embodied in any such megafunction design, netlist, -- support information, device programming or simulation file, or any other -- related documentation or information provided by Altera or a megafunction -- partner, remains with Altera, the megafunction partner, or their respective -- licensors. No other licenses, including any licenses needed under any third -- party's intellectual property, are provided herein. -- VENDOR "Altera" -- PROGRAM "Quartus II" -- VERSION "Version 4.2 Build 178 01/19/2005 Service Pack 1 SJ Full Version" -- DATE "02/18/2005 13:34:52" -- -- Device: Altera EP20K200EQC208-1 Package PQFP208 -- -- -- This VHDL file should be used for MODELSIM (VHDL OUTPUT FROM QUARTUS II) only -- LIBRARY IEEE, apex20ke; USE IEEE.std_logic_1164.all; USE apex20ke.apex20ke_components.all; ENTITY add_sub_alu_synt IS PORT ( enable : IN std_logic; clk : IN std_logic; do_hold : IN std_logic; rst : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; enable_in : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); start : IN std_logic; data_out : OUT std_logic_vector(3 DOWNTO 0) ); END add_sub_alu_synt; ARCHITECTURE structure OF add_sub_alu_synt IS SIGNAL gnd : std_logic := '0'; SIGNAL vcc : std_logic := '1'; SIGNAL devclrn : std_logic := '1'; SIGNAL devpor : std_logic := '1'; SIGNAL devoe : std_logic := '0'; SIGNAL ww_enable : std_logic; SIGNAL ww_clk : std_logic; SIGNAL ww_do_hold : std_logic; SIGNAL ww_rst : std_logic; SIGNAL ww_do_add : std_logic; SIGNAL ww_do_subtract : std_logic; SIGNAL ww_enable_in : std_logic; SIGNAL ww_data_in : std_logic_vector(3 DOWNTO 0); SIGNAL ww_start : std_logic; SIGNAL ww_data_out : std_logic_vector(3 DOWNTO 0); SIGNAL if0a5x13_aCOMBOUT : std_logic; SIGNAL start_acombout : std_logic; SIGNAL data_in_a2_a_acombout : std_logic; SIGNAL do_subtract_acombout : std_logic; SIGNAL do_hold_acombout : std_logic; SIGNAL n5831x3 : std_logic; SIGNAL do_add_acombout : std_logic; SIGNAL n5831x2 : std_logic; SIGNAL clk_acombout : std_logic; SIGNAL rst_acombout : std_logic; SIGNAL n544cx3 : std_logic; SIGNAL n544cx2 : std_logic; SIGNAL state_var_1 : std_logic; SIGNAL data_in_a0_a_acombout : std_logic; SIGNAL enable_in_acombout : std_logic; SIGNAL latched_data_in_0 : std_logic; SIGNAL nfc54x2 : std_logic; SIGNAL cin : std_logic; SIGNAL a_2_dup_240 : std_logic; SIGNAL nf0a5x2 : std_logic; SIGNAL reg_0 : std_logic; SIGNAL enable_acombout : std_logic; SIGNAL data_in_a1_a_acombout : std_logic; SIGNAL latched_data_in_1 : std_logic; SIGNAL nf0a5x8 : std_logic; SIGNAL nf0a5x10 : std_logic; SIGNAL nf0a5x9 : std_logic; SIGNAL a_2_dup_239 : std_logic; SIGNAL reg_1 : std_logic; SIGNAL latched_data_in_2 : std_logic; SIGNAL nf0a5x6 : std_logic; SIGNAL nf0a5x7 : std_logic; SIGNAL a_2_dup_238 : std_logic; SIGNAL reg_2 : std_logic; SIGNAL data_in_a3_a_acombout : std_logic; SIGNAL latched_data_in_3 : std_logic; SIGNAL nf0a5x4 : std_logic; SIGNAL nf0a5x5 : std_logic; SIGNAL a_2 : std_logic; SIGNAL reg_3 : std_logic; SIGNAL ALT_INV_rst_acombout : std_logic; BEGIN ww_enable <= enable; ww_clk <= clk; ww_do_hold <= do_hold; ww_rst <= rst; ww_do_add <= do_add; ww_do_subtract <= do_subtract; ww_enable_in <= enable_in; ww_data_in <= data_in; ww_start <= start; data_out <= ww_data_out; ALT_INV_rst_acombout <= NOT rst_acombout; start_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_start, combout => start_acombout); data_in_ibuf_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(2), combout => data_in_a2_a_acombout); do_subtract_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_subtract, combout => do_subtract_acombout); do_hold_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_hold, combout => do_hold_acombout); ib0e1x3 : apex20ke_lcell -- Equation(s): -- n5831x3 = do_hold_acombout & state_var_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datac => do_hold_acombout, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x3); do_add_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_do_add, combout => do_add_acombout); ib0e1x2 : apex20ke_lcell -- Equation(s): -- n5831x2 = n544cx3 & state_var_1 & !do_subtract_acombout # !state_var_1 & !start_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "3050", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => start_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n5831x2); clk_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_clk, combout => clk_acombout); rst_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_rst, combout => rst_acombout); reg_state_var_0 : apex20ke_lcell -- Equation(s): -- n544cx3 = DFFE(n5831x3 # n5831x2 # !n544cx3 & do_add_acombout, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FFDC", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => n544cx3, datab => n5831x3, datac => do_add_acombout, datad => n5831x2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => n544cx3); ib0e2x3 : apex20ke_lcell -- Equation(s): -- n544cx2 = !n544cx3 & !state_var_1 & do_add_acombout # do_subtract_acombout -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "000E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => do_add_acombout, datab => do_subtract_acombout, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => n544cx2); reg_state_var_1 : apex20ke_lcell -- Equation(s): -- state_var_1 = DFFE(n544cx2 # !do_hold_acombout & state_var_1, GLOBAL(clk_acombout), GLOBAL(rst_acombout), , ) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FF50", output_mode => "reg_only") -- pragma translate_on PORT MAP ( dataa => do_hold_acombout, datac => state_var_1, datad => n544cx2, clk => clk_acombout, aclr => ALT_INV_rst_acombout, devclrn => devclrn, devpor => devpor, regout => state_var_1); data_in_ibuf_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(0), combout => data_in_a0_a_acombout); enable_in_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable_in, combout => enable_in_acombout); id8dfx3 : apex20ke_lcell -- Equation(s): -- latched_data_in_0 = enable_in_acombout & data_in_a0_a_acombout # !enable_in_acombout & latched_data_in_0 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CACA", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => latched_data_in_0, datab => data_in_a0_a_acombout, datac => enable_in_acombout, devclrn => devclrn, devpor => devpor, combout => latched_data_in_0); id8dfx2 : apex20ke_lcell -- Equation(s): -- nfc54x2 = latched_data_in_0 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_0, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nfc54x2); id8dfx1 : apex20ke_lcell -- Equation(s): -- cin = state_var_1 & !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "00CC", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => cin); ifc54x2 : apex20ke_lcell -- Equation(s): -- a_2_dup_240 = nfc54x2 $ reg_0 $ cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C33C", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => nfc54x2, datac => reg_0, datad => cin, devclrn => devclrn, devpor => devpor, combout => a_2_dup_240); i197dx1 : apex20ke_lcell -- Equation(s): -- nf0a5x2 = state_var_1 # !n544cx3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CCFF", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x2); reg_reg_0 : apex20ke_lcell -- Equation(s): -- reg_0 = DFFE(a_2_dup_240 & state_var_1, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => a_2_dup_240, datad => state_var_1, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_0); enable_ibuf : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_enable, combout => enable_acombout); data_in_ibuf_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(1), combout => data_in_a1_a_acombout); i2456x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_1 = enable_in_acombout & data_in_a1_a_acombout # !enable_in_acombout & latched_data_in_1 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "CFC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => data_in_a1_a_acombout, datac => enable_in_acombout, datad => latched_data_in_1, devclrn => devclrn, devpor => devpor, combout => latched_data_in_1); i2456x1 : apex20ke_lcell -- Equation(s): -- nf0a5x8 = latched_data_in_1 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_1, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x8); if0a5x14 : apex20ke_lcell -- Equation(s): -- nf0a5x10 = reg_0 & nfc54x2 # cin # !reg_0 & nfc54x2 & cin -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "FCC0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => reg_0, datac => nfc54x2, datad => cin, devclrn => devclrn, devpor => devpor, combout => nf0a5x10); if0a5x13 : apex20ke_lcell -- Equation(s): -- nf0a5x9 = CARRY(nf0a5x10) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", packed_mode => "false", lut_mask => "00CC", output_mode => "none") -- pragma translate_on PORT MAP ( datab => nf0a5x10, devclrn => devclrn, devpor => devpor, cout => nf0a5x9); if0a5x10 : apex20ke_lcell -- Equation(s): -- a_2_dup_239 = reg_1 $ nf0a5x8 $ nf0a5x9 -- nf0a5x7 = CARRY(reg_1 & !nf0a5x8 & !nf0a5x9 # !reg_1 & !nf0a5x9 # !nf0a5x8) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "9617", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_1, datab => nf0a5x8, cin => nf0a5x9, devclrn => devclrn, devpor => devpor, combout => a_2_dup_239, cout => nf0a5x7); reg_reg_1 : apex20ke_lcell -- Equation(s): -- reg_1 = DFFE(state_var_1 & a_2_dup_239, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_239, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_1); ia9f8x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_2 = enable_in_acombout & data_in_a2_a_acombout # !enable_in_acombout & latched_data_in_2 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "AFA0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => data_in_a2_a_acombout, datac => enable_in_acombout, datad => latched_data_in_2, devclrn => devclrn, devpor => devpor, combout => latched_data_in_2); ia9f8x1 : apex20ke_lcell -- Equation(s): -- nf0a5x6 = latched_data_in_2 $ (!state_var_1 # !n544cx3) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C333", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => latched_data_in_2, datac => n544cx3, datad => state_var_1, devclrn => devclrn, devpor => devpor, combout => nf0a5x6); if0a5x7 : apex20ke_lcell -- Equation(s): -- a_2_dup_238 = reg_2 $ nf0a5x6 $ !nf0a5x7 -- nf0a5x5 = CARRY(reg_2 & nf0a5x6 # !nf0a5x7 # !reg_2 & nf0a5x6 & !nf0a5x7) -- pragma translate_off GENERIC MAP ( operation_mode => "arithmetic", cin_used => "true", packed_mode => "false", lut_mask => "698E", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_2, datab => nf0a5x6, cin => nf0a5x7, devclrn => devclrn, devpor => devpor, combout => a_2_dup_238, cout => nf0a5x5); reg_reg_2 : apex20ke_lcell -- Equation(s): -- reg_2 = DFFE(state_var_1 & a_2_dup_238, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2_dup_238, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_2); data_in_ibuf_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "input", reg_source_mode => "none", feedback_mode => "from_pin", power_up => "low") -- pragma translate_on PORT MAP ( devclrn => devclrn, devpor => devpor, devoe => devoe, oe => GND, ena => VCC, padio => ww_data_in(3), combout => data_in_a3_a_acombout); ia9f5x2 : apex20ke_lcell -- Equation(s): -- latched_data_in_3 = enable_in_acombout & data_in_a3_a_acombout # !enable_in_acombout & latched_data_in_3 -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F5A0", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => enable_in_acombout, datac => data_in_a3_a_acombout, datad => latched_data_in_3, devclrn => devclrn, devpor => devpor, combout => latched_data_in_3); ia9f5x1 : apex20ke_lcell -- Equation(s): -- nf0a5x4 = latched_data_in_3 $ (!n544cx3 # !state_var_1) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "C30F", output_mode => "comb_only") -- pragma translate_on PORT MAP ( datab => state_var_1, datac => latched_data_in_3, datad => n544cx3, devclrn => devclrn, devpor => devpor, combout => nf0a5x4); if0a5x4 : apex20ke_lcell -- Equation(s): -- a_2 = reg_3 $ (nf0a5x5 $ nf0a5x4) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", cin_used => "true", packed_mode => "false", lut_mask => "A55A", output_mode => "comb_only") -- pragma translate_on PORT MAP ( dataa => reg_3, datad => nf0a5x4, cin => nf0a5x5, devclrn => devclrn, devpor => devpor, combout => a_2); reg_reg_3 : apex20ke_lcell -- Equation(s): -- reg_3 = DFFE(state_var_1 & a_2, GLOBAL(clk_acombout), , , nf0a5x2) -- pragma translate_off GENERIC MAP ( operation_mode => "normal", packed_mode => "false", lut_mask => "F000", output_mode => "reg_only") -- pragma translate_on PORT MAP ( datac => state_var_1, datad => a_2, clk => clk_acombout, ena => nf0a5x2, devclrn => devclrn, devpor => devpor, regout => reg_3); tri_data_out_0 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_0, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(0)); tri_data_out_1 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_1, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(1)); tri_data_out_2 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_2, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(2)); tri_data_out_3 : apex20ke_io -- pragma translate_off GENERIC MAP ( operation_mode => "output", reg_source_mode => "none", feedback_mode => "none", power_up => "low") -- pragma translate_on PORT MAP ( datain => reg_3, oe => enable_acombout, devclrn => devclrn, devpor => devpor, devoe => devoe, ena => VCC, padio => ww_data_out(3)); END structure; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 34e2a6cf70b8111604d8e5d98e1877bfd8bfc8f6 0 111 395 2009-03-30T12:37:37Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |TTi EL155 |15V, 5A linear DC power supply | |- |TTi EL302D |30V, 2A dual linear DC power supply | |- |TTi QL355TP |15V, 5A | 35V, 3A | 35V, 0,5A + Aux, dual DC power supply | |- |TTi QPX1200 |60V, 50A linear DC power supply | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} 529d0e6b4157da5af3fd9ad30e427c8e21b1726b 396 2009-03-30T12:39:36Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |TTi EL155 |15V, 5A linear DC power supply | |- |TTi EL302D |30V, 2A dual linear DC power supply | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply | |- |TTi QPX1200 |60V, 50A linear DC power supply | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} 2365c3626a34187610fd120331033de948643878 397 2009-04-06T09:11:23Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |TTi EL155 |15V, 5A linear DC power supply | |- |TTi EL302D |30V, 2A dual linear DC power supply | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} dc64143620c31dd173e7027f180598354eb6ad4b 398 2009-04-06T09:11:55Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |TTi EL155 |15V, 5A linear DC power supply | |- |TTi EL302D |30V, 2A dual linear DC power supply | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} 8a700e385f9eda9bf463ab6be0cab427ecb978d0 399 2009-04-06T09:16:03Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} f808628e9ae32cef56ed7635c236632c05f78726 400 2009-04-06T09:21:30Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} 7b3f3377802404f5cbdbd0be0c836a6babc90fa4 401 2009-04-06T09:28:27Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |} = Pulse Generators = {| border="1" cellpadding "5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Philips PM 5715 |Pulse / Waveform Generator 50 Mhz | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} bc8872e6ff01a33008e2470ea17f9d8045775b55 402 2009-04-06T09:29:21Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Philips PM 5715 |Pulse / Waveform Generator 50 Mhz | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} 73d15202dba9ce094a83be9069196365eba8b02a 406 2009-04-14T07:46:42Z St12361 17 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Philips PM 5715 |Pulse / Waveform Generator 50 Mhz | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[http://www.bt.no Info]] |} c878b2e54d15e0a726f4a0e6b3b95134dbe88d10 408 2009-04-14T07:55:57Z St12361 17 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Philips PM 5715 |Pulse / Waveform Generator 50 Mhz | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} ea5aaba03d9b5a73181daa58f6b7ea2eb8acb828 411 2009-04-15T09:55:27Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator | |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} e6f065331ae4d394799e815819cfaa196bc51f97 2 161 403 2009-04-08T19:21:56Z Tbu082 19 New page: Anna Lipniacka wikitext text/x-wiki Anna Lipniacka e4b8f1b1d2163e7eabde80497f44469ab12d753d 0 22 407 2009-04-14T07:51:39Z St12361 17 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === [[Image:MAPD_radiotracer.JPG‎|frame|right|200px|Fluorodeoxyglucose-FDG]] [[Image:MAPD_positronelectronannihilation.JPG‎‎|frame|left|200px|Positron - Electron Annihilation]] The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === [[Image:MAPD_crystaltransition.JPG‎ |frame|left|200px|Electronic transition in a crystal]] A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === [[Image:MAPD_coincidenceprinciple.JPG‎ |frame|none|200px|Coincidence detection principle]] In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. [[Image:MAPD_coincidencecategories.JPG|frame||200px|3 different coincidence detection events]] * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. [[Image:MAPD tofprinciple.jpg‎ |frame|none|200px|Time of flight principle]] [[Image:MAPD tofprinciple2.JPG|frame|none|200px|Time of flight principle]] == Technology == === Avalanche Photodiodes === [[Image:MAPD structure.jpg‎|frame|right|200px|Structure of MAPD]] An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. [[Image:MAPD proportionalmode.jpg‎ ‎|frame|right|200px|proportional mode]] * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. [[Image:MAPD geigermode.jpg‎‎|frame|right|200px|Geiger mode]] [[Image:MAPD_passivequenching.jpg‎‎|frame|right|200px|passive quenching]] The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. == Characterisation Cell == == Characterisation setup and results == [[User:Dfe002|Dominik]] 09:04, 12 March 2009 (CET) [[Category:Detector lab]] 37870b2cad8c9376dfd26b0b0920b6076963d22f 0 83 409 2009-04-14T08:01:35Z St12361 17 wikitext text/x-wiki ==Critical Parameters== {| border="1" cellpadding="5" cellspacing="0" !Parameter !Description !Typical Value (Fast PTM) !H6780-02 |- |Rise Time (TR) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |0,05 (MCP) to 3 ns |0,78 ns (0,2 s settling time) |- |Transit Time (TT) |The time interval between the arrival of photon at the cathode and the arrival of the amplified pulse at the anode |MCP:0,5 ns. PMT: 5-30 ns | |- |Transit Time Spread (TTS) |Considered as the most important specification for time-resolved measurements; the timing variation due to the different geometric paths that the electrons can take from the cathode to the anode |MCP: 0,025 ns. PMT: 0,2-1,5 ns |} <BR /> [[Image:PMT_Parameters.jpg]] ==Overview of different PMT's== {| border="1" cellpadding="2" cellspacing="0" !Part ID !Type !Driving Voltage !Gain !Spectral Range (nm) !Spectral Peak (nm) !Dark Current (after 30 min) !Rise Time (ns) !Transit Time (TT)(ns) !Transit Time Spread (TTS) (ns) !Pricing |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r1166.php R1161] |PMT - Head On |1000 V |1,0E+06 |300 to 650 |420 |1-6 nA |2,5 |27 |2,8 |x |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5509-42.php R5505] |PMT - Head On |1750 V |1,0E+06 |300 to 1400 |900 |10 nA |3 |23 |1,5 |16 010 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3478.php R3478] |PMT - Head On |1700 V |1,7E+06 |300 to 650 |420 |6 nA |1,3 |14 |0,36 |3 837 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u-02.php 7400U-02] |PMT - Head On |800 V |5,0E+05 |300 to 850 |500 |2 nA |0,78 |5,4 |0,23 |6 404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r2083.php R2083] |PMT - Head On |3000 V |2,5E+06 |300 to 650 |420 |100 nA |0,7 |16 |0,37 |14 955 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r7400u.php 7400-02] |PMT - Head On |800 V |7,0E+05 |300 to 850 |420 |0,2 nA |0,75 |5,4 |0,28 |6404 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r3809u-52.php R3809-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |2000/s |0,15 |0,55 |0,025 |126 346 SEK |- |[http://sales.hamamatsu.com/en/products/electron-tube-division/detectors/photomultiplier-tubes/part-r5916u-52.php R5916U-52] |MCP - PMT |3000 V |2,0E+05 |160 to 650 |400 |0,5 |0,18 |1 |0,09 |148 643 SEK |} ===So whats's up with the MCP's?=== Microchannel Plate PMT, has plates containing numerous small holes, microchannels, which are lined with a secondary emissive dynode material. Electrons are amplified as they drop down the voltage gradients across the microchannel plate. MCP-PMT shows the fastes time response due to the restricted range of electron paths and short electron travel distance. Disadvantage is lower gain and photocurrent typ at 100 nA vs. 10-100uA for dyanode PMT <BR /> [[Image:MCP-PMT.jpg]] 93049a668858d07a557f6e5654f09c906f309abc 2 162 410 2009-04-15T09:52:06Z Dfe002 7 New page: Therese Sjursen wikitext text/x-wiki Therese Sjursen fb07ac5930cd7e87a84b1760eed07ac67e5f939d 6 133 412 260 2009-04-21T05:30:40Z Dfe002 7 uploaded a new version of "[[File:3D tpccpower.JPG]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 139 415 371 2009-04-23T20:11:20Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 27040efb56cc56cba88114aaffa3dc3e454ac35c 0 157 429 428 2009-04-24T11:45:11Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre>sh /work2/atlas/install_scripts/list_athena_release.sh</pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre>source /work2/atlas/install_scripts/setup_athena.sh version</pre> (where version is one in the previous list) #* to get a work area use <pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands<pre>chown -R ${USER}:atlasuib /work/${USER} /work2/${USER}; chmod -R g+r /work/${USER} /work2/${USER}</pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files # With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre>ssh -X ${USER}@fimm.bccs.uib.no</pre> <pre>qsub -I -X</pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre>source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3</pre><pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 5ab8996847fa62986e662798d0f980885127252a 430 429 2009-04-24T11:45:47Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre>sh /work2/atlas/install_scripts/list_athena_release.sh</pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre>source /work2/atlas/install_scripts/setup_athena.sh version</pre> (where version is one in the previous list) #* to get a work area use <pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre>chown -R ${USER}:atlasuib /work/${USER} /work2/${USER}; chmod -R g+r /work/${USER} /work2/${USER}</pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files # With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome <pre>ssh -X ${USER}@fimm.bccs.uib.no</pre> <pre>qsub -I -X</pre> (the -X's are for X window forwarding, you must use these) (wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea <pre>source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3</pre><pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 4a4979c76ff7889a70ffff8c1ed3a73dec0ba369 431 430 2009-04-24T11:46:40Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre>sh /work2/atlas/install_scripts/list_athena_release.sh</pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre>source /work2/atlas/install_scripts/setup_athena.sh version</pre> (where version is one in the previous list) #* to get a work area use <pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre>chown -R ${USER}:atlasuib /work/${USER} /work2/${USER}; chmod -R g+r /work/${USER} /work2/${USER}</pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files # With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome #:<pre>ssh -X ${USER}@fimm.bccs.uib.no</pre> #:<pre>qsub -I -X</pre> #:(the -X's are for X window forwarding, you must use these) #:(wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea #:<pre>source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3</pre> #:<pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> #:and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] 131402e6938b74b53d8ae8f6932413dc520f7b18 432 431 2009-04-24T11:47:26Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use <pre>sh /work2/atlas/install_scripts/list_athena_release.sh</pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre>source /work2/atlas/install_scripts/setup_athena.sh version</pre> (where version is one in the previous list) #* to get a work area use #*:<pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands <pre>chown -R ${USER}:atlasuib /work/${USER} /work2/${USER}; chmod -R g+r /work/${USER} /work2/${USER}</pre> and in case you have something in <tt>/workX/users/</tt> do the same for these files # With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome #:<pre>ssh -X ${USER}@fimm.bccs.uib.no</pre> #:<pre>qsub -I -X</pre> #:(the -X's are for X window forwarding, you must use these) #:(wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea #:<pre>source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3</pre> #:<pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> #:and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] d9b8cab56b497738931bc883a7b296fe3163206d 433 432 2009-04-24T11:48:01Z Tbu082 19 wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == https://wikihost.uib.no/ift/images/d/de/FimmWorkshop18.03.09v2.pdf === Update === A number of things changed on fimm since the workshop 19/3-09 # <tt>/work/atlas</tt> was broken by some cleaning script! for now use <tt>/work2/atlas</tt> instead # I have removed the old atlas installations, we now use the grid installations #* to see what versions are available use #*: <pre>sh /work2/atlas/install_scripts/list_athena_release.sh</pre> #:(current list: 14.2.10 14.2.10.1 14.2.23 14.2.23.2 14.2.23.3 14.2.25 14.2.25.6 14.2.25.8 14.5.0 14.5.0.7 14.5.1 14.5.1.2 14.5.1.3 14.5.2 14.5.2.1 14.5.2.2 14.5.2.3 15.0.0) #* to get an athena environment use <pre>source /work2/atlas/install_scripts/setup_athena.sh version</pre> (where version is one in the previous list) #* to get a work area use #*: <pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> # for now dq2 is broken, avoid it, if you need it use it on lxplus and scp the files to fimm # make sure everyone can see your files, please run the following commands #: <pre>chown -R ${USER}:atlasuib /work/${USER} /work2/${USER}; chmod -R g+r /work/${USER} /work2/${USER}</pre> #: and in case you have something in <tt>/workX/users/</tt> do the same for these files # With interactive jobs one can run ATLAS eventviewers on fimm, try it - its awesome #:<pre>ssh -X ${USER}@fimm.bccs.uib.no</pre> #:<pre>qsub -I -X</pre> #:(the -X's are for X window forwarding, you must use these) #:(wait until prompt changes to interactive job, often quick, but can take some minutes) in the job get a workarea #:<pre>source /work2/atlas/install_scripts/setup_athena.sh 14.5.2.3</pre> #:<pre>source /work2/atlas/install_scripts/setup_athena_workarea.sh</pre> #:and in the prompt run either <tt>atlantis</tt> or <tt>vp1</tt> == Program == * Intro to fimm - the parallab linux cluster ** What is there ** How to get an account ** The file system * How to submit a simple job ** PBS scripts ** PBS commands * What is in the ATLAS work directory * Using root in a job * Using athena in a job * Using nordugrid & dq2 == Evo connection information == People at CERN can connect from the office in building 21, it should be empty now anyway. There is a duet mic/speaker device there already. <pre> Title: Bergen parallab workshop I Description: Workshop for Bergen ATLAS people on how to use the parallab resources Community: ATLAS Password: ATLASFimm Time: 2009-03-18 12:00-15:00 (meeting starts 12:30) Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=eleBevvavDalatIuanIl Phone Bridge: ID: 863906 Password: 0686 Swiss: +41 22 76 71400 </pre> [[Category:Particle Physics]] b83967a72a18d76d739e532f0a8856985d325c31 0 137 434 405 2009-05-03T09:26:13Z St11874 25 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 070327923e0b7cef9b562ae4738474f37797b30c 0 139 451 415 2009-05-05T08:09:08Z St11874 25 wikitext text/x-wiki == Particle Physics Group Meetings == [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 1a275d6b595fffe831df9614bb1e2ad482f97d99 0 165 452 2009-05-05T08:15:52Z St11874 25 Created page with '=== Connecting === The meeting will be held 12:00-13:00 on Tuesday, 5th of May, 2009. === Agenda === * OTP requirements (Anna) * Shift information and plans (Therese) * Fimm ne...' wikitext text/x-wiki === Connecting === The meeting will be held 12:00-13:00 on Tuesday, 5th of May, 2009. === Agenda === * OTP requirements (Anna) * Shift information and plans (Therese) * Fimm news (Thomas) * AOB [[media:Shifts@ATLAS]] --Therese 05.05.2009 feac66fe5cadaf9c608654d039eb2918fee8315b 455 452 2009-05-05T09:16:44Z St11874 25 wikitext text/x-wiki === Connecting === The meeting will be held 12:00-13:00 on Tuesday, 5th of May, 2009. === Agenda === * OTP requirements (Anna) * Shift information and plans (Therese) * Fimm news (Thomas) * AOB [[File:Shifts@ATLAS.pdf]] --Therese 05.05.2009 11a8531aa9ed1aa2080a59421f4493079b0334a5 6 166 453 2009-05-05T09:13:20Z St11874 25 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 167 454 2009-05-05T09:14:50Z St11874 25 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2 168 458 2009-05-05T12:36:47Z Tbu082 19 Created page with 'Maren Ugland' wikitext text/x-wiki Maren Ugland 4126381d08a3ee97bc02ecf9edbdf6e9d90e6ca8 0 1 459 369 2009-05-06T07:34:46Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 68f39ba3813159d60ddb23d1f79c9aecc7a57347 0 25 460 218 2009-05-12T11:49:36Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[PHYS321]] Øvingsoppgaver i PHYS321 [[Category:Mikroelektronikk]] 7cfa3b9e29c6327915f4b5f355515656770ecdd4 0 169 461 2009-05-12T11:57:26Z Nfyku 4 Created page with '== Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC Studio IC Studio]] Du skal tegne en 6 transistor SRAM-celle m...' wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC Studio IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virkwer som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygegs opp. [[Category:Mikroelektronikk]] 5d151d3e96da4236b3ef134e2617c6450977404f 462 461 2009-05-12T12:00:50Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[:Wikipedia:IC_Studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygegs opp. [[Category:Mikroelektronikk]] edcea6cb3492b0741837e93ee9528b017500d26a 463 462 2009-05-12T12:01:47Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC_Studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. [[Category:Mikroelektronikk]] 5f50ed11ee99aa843a466beb47107795f3750773 464 463 2009-05-12T12:10:14Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[Media:IC Studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. [[Category:Mikroelektronikk]] 0ca1ce9c41e5886260f13d705fa683d586449ab4 465 464 2009-05-12T12:14:19Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[:IC Studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. [[Category:Mikroelektronikk]] 098f98a38724ab298042f200430ab16e207b753d 466 465 2009-05-12T12:14:39Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[:IC_Studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. [[Category:Mikroelektronikk]] 813094a0bfc539269e05767ae33c531e0dfa363d 467 466 2009-05-12T12:18:49Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC_Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. [[Category:Mikroelektronikk]] e06238ae6c2973dd90b28ee408df1d72a92981ce 468 467 2009-05-12T12:19:36Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC_studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. [[Category:Mikroelektronikk]] de4199254dc8d8b165f9e829fc8bd537bcb66eac 0 111 469 411 2009-05-19T06:26:50Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |Reference manual |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator | |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 579f409b57765419fa3520c243b0ad5de58d0a1c 471 469 2009-05-19T06:28:33Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[[File:Keithley2635a.pdf Reference manual]] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator | |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 7dd8b19aa5849f448684d8074435f58092e48ccb 472 471 2009-05-19T06:30:55Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter | |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual]] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator | |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 1ac0afd6c90db50f7a5c8cc72c2fcbaea2a78037 474 472 2009-05-19T06:34:11Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel | |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual]] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual]] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator | |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 3063f0a979d3b662e138940c8f59fbf64f56377d 476 474 2009-05-19T06:37:36Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual]] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual]] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual]] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator | |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} baa55c5a2fdc9736795488d9e0bfdecb249be0e1 479 476 2009-05-19T06:48:08Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual]] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual]] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual]] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator | |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual]] [[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual]] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} bc5c4a309d5678fc2bdf46c2e6e6594206419c74 480 479 2009-05-19T06:49:38Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual]] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual]] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual]] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual]] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual]] [[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual]] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[[http://www.phillipsscientific.com/pdf/6954ds.pdf Info]] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[[http://www.ortec-online.com/pdf/vt120.pdf Info]] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info]] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} f586e030ce6ef67ff6c09e9ff6086f52bff6490a 481 480 2009-05-19T06:50:52Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s | |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 107dec7f6b4eb1534166554039a347c45c0e1c44 482 481 2009-05-19T07:33:24Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s | |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} b5efdd41ea5dd1eea35a3b1c10b5801d86b1fc27 485 482 2009-05-19T07:34:35Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB | |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 0f215abf083ed7ad76a34919b8249652f8369ba0 488 485 2009-05-19T07:52:02Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller | |- |Caen V2718 |VME controller | |- |Caen V1729a |14 bit, 4 channel ADC | |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 57ef743e2aaf0b063540031647d2cd33b53a9a39 492 488 2009-05-19T08:04:32Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] |- |Caen V965a |QDC | |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} cb3b01731509fec56b9fd8f2fd57e9dec686aaca 494 492 2009-05-19T08:06:29Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 78a335a631dd48e64e3ea5b568a8bfbb15845bc0 496 494 2009-05-19T08:13:46Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] |} a23284ca55957184e4c7742c2313fa9e7c90d47e 6 170 470 2009-05-19T06:27:54Z Dfe002 7 Keithley2635a.pdf Sourcemeter reference manual wikitext text/x-wiki Keithley2635a.pdf Sourcemeter reference manual 7d404927b89acbd2672eeed3fca687e72a972560 6 171 473 2009-05-19T06:33:37Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 172 475 2009-05-19T06:37:07Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 173 477 2009-05-19T06:46:51Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 174 478 2009-05-19T06:47:04Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 175 483 2009-05-19T07:33:34Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 176 484 2009-05-19T07:33:48Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 177 486 2009-05-19T07:51:01Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 178 487 2009-05-19T07:51:44Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 179 489 2009-05-19T07:57:34Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 180 490 2009-05-19T08:00:56Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 181 491 2009-05-19T08:04:18Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 182 493 2009-05-19T08:06:05Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 183 495 2009-05-19T08:13:25Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 111 497 496 2009-05-19T08:14:38Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 9b60973be920a3e7ac1d540f1cdc1dea35851839 2 184 498 2009-05-19T15:57:54Z Tbu082 19 Created page with 'Alette Åsvold' wikitext text/x-wiki Alette Åsvold 8b414bfcfcdf98da1aa459ceb1ae2d495320455f 499 498 2009-05-20T06:37:40Z Aaa014 28 wikitext text/x-wiki Alette Aasvold 9b1236d8deacdddc06f9624cf598c6090fc62ffa 0 3 501 162 2009-05-20T10:54:10Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 272be53238bc4d45c790fbf5a189c689f8cd3089 502 501 2009-05-20T11:15:29Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Added firmware register to 0x2015 </li> <li> Updated Busy Controller module to handle orphan messages </li> </ul> <br> === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] e9bafbe319ecab2a294c7d216bfda4ebf801874a 503 502 2009-05-20T11:16:01Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware register added to 0x2015 </li> <li> Updated Busy Controller module to handle orphan messages </li> </ul> <br> === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] f16de0f6c57bfca4550f7701e89df1447d4d3465 504 503 2009-05-20T11:16:36Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 6ab0b8f07bcc27b6cfe36874886af27dcd30891d 505 504 2009-05-20T11:18:39Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] fcea1295c15044da176015d6a2e8ad67dbab20bd 507 505 2009-05-20T11:29:16Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/~alme/wiki/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] eeedf54010bf7a80c1f4181e255ab81182e6e7a0 508 507 2009-05-20T11:32:46Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎]] <br> Source files: [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br><br> <ul> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 4fbe5e0a60541dff6cb19dd2e085906ea3e49a90 509 508 2009-05-20T11:34:07Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎|User_guide_busybox.pdf‎]] <br> Source files: [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br><br> <ul> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 156b62f94a673d21804bf0d7266f99c6baf2490a 510 509 2009-05-20T11:38:02Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎]] | <br> Source files: [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br><br> <ul> <li>'''Version 1.0: '''<br> [http://www.ift.uib.no/~alme/wiki/armboot_v2.2.bin armboot_v2.2.bin] | [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] abc6cd84f72776bc5b00f5e01927aeff8316a9ef 511 510 2009-05-20T11:49:29Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎]] | <br> Source files: [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br><br> <ul> <li>'''Version 1.01: '''<br> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit] | [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] e88e96597b0075713c498c9a32924f79094341f7 512 511 2009-05-20T11:51:22Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎]] | <br> Source files: [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br><br> <ul> <li>'''Version 1.01: '''<br> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] | </li> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 86f8c30380f0de05c4e98962866320636bf4944b 513 512 2009-05-20T11:52:42Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎]] | <br> Source files: [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br><br> <ul> BusyBox firmware:<br> <li>'''Version 1.01: '''<br> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] | </li> <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 9143fed335ba5537f34a5923d2c01fd1d3fd3e59 514 513 2009-05-20T11:54:20Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎]] | <br> Source files: [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br><br> <ul> BusyBox firmware:<br> <li>'''Version 1.01: '''<br> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </li> <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] c1f2bcdad351cd1f39f36dc072f065336d8054e6 515 514 2009-05-20T11:55:30Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> <ul> BusyBox firmware:<br> <li>'''Version 1.01: '''<br> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </li> <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 7a19bba066ec99cbeae64ea8118809c3077643b4 516 515 2009-05-20T11:56:24Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <li>'''Version 1.01: '''<br> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </li> <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] a1e1b4ee749ffbd101d8c7f41e69e21f86737750 517 516 2009-05-20T11:59:29Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </li> <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 2c5284d304faa3cac7313bf5d4a44b03dbc625b3 518 517 2009-05-20T12:11:32Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </li> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | DCS BusyBox firmware]] [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 386e8db961b3b1141ded6ece440e7ebab5dfef30 519 518 2009-05-20T12:12:51Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </li> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | DCS BusyBox firmware]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 7ed47e7e6067246ca0303ffac06173d724519de7 520 519 2009-05-20T12:13:37Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | DCS BusyBox firmware]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 7343f080b5a3d2957bc5550f22ca41291ddedf42 521 520 2009-05-20T12:14:29Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | DCS BusyBox firmware]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] c1daa9aad921513b72f795b281f5e42062bead1e 522 521 2009-05-20T12:15:17Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | DCS firmware]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] c2eb8932a684dd1e738ba6dd3629655a8e62bb83 523 522 2009-05-20T12:16:11Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | DCS firmware]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] 0ec168d24fdb8925bbea8698d631b9af2ca29871 524 523 2009-05-20T12:16:35Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | DCS firmware]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] [[Category:Alice]] [[Category:Trigger]] bb859b0635149517a442ec10848e143b7f287861 525 524 2009-05-20T12:18:41Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Media:bb_manual.pdf|User Guide BusyBox, Rikard Bølgen]] <br> [[Category:Alice]] [[Category:Trigger]] 81aa1f80f2dd5374e4f4f66ba557d3d2bfb52fa2 526 525 2009-05-20T12:19:31Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] fcfa66973e8893bce8e3ed2e8f402e4d36fb5c84 527 526 2009-05-20T12:24:14Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ | CVS for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 2e55c374a22cfc0bdc0b9c79c32913841c46cfb2 528 527 2009-05-20T12:26:01Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ | CVS for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 4bf1eab452240bd97a97a40dad4205541f95ea5f 529 528 2009-05-20T12:27:17Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware | SVN database][http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ | CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ | CVS for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] de144350bab07a1b435465b5348c5b5322b7d594 530 529 2009-05-20T12:28:10Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database]|[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ | CVS for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] f2bb67b3806397902c6ad83991ebad7fa9b24579 531 530 2009-05-20T12:28:25Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit | busybox_fpga1.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit | busybox_fpga2.bit] [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit | busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ | CVS for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] acbfb5d4acdeaeb6f455355f69cf5d5f1ed423f9 532 531 2009-05-20T12:29:00Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ | CVS for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section | BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] a025ae3201a87336b5c6b0fbb67a6b04ffe91f48 533 532 2009-05-20T12:29:30Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ CVS for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] c31e12df818dedb39ec948d58511cd4c1b892d53 534 533 2009-05-20T12:30:23Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 7afb02eb2f6a6e048976bdc94fa0517ba5d3c6a8 535 534 2009-05-20T12:31:10Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> DCS board firmware for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section BUSYBOX]] <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] e230f0c710dec9d3230931ca0fba7d7b5f954e57 536 535 2009-05-20T12:33:14Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section BUSYBOX]] </ul> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 137dc57fee1605648e8fe5cc34759cd9a1793c72 537 536 2009-05-20T12:34:47Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] a5aa5dcedb9bec8871095102895c99c6d3e22ce8 538 537 2009-05-20T12:36:54Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 6f9de9755e8d93bb7378c309b557c6bc20490a93 539 538 2009-05-20T12:37:37Z Rbo021 13 wikitext text/x-wiki == Overview == Traditionally the Fee in ALICE sub-detectors indicates when its buffers are full and cannot handle further triggers from the CTP. This is either done directly or through the FANIN module to the LTU with a busy signal. Due to dense cabling, four of the ALICE sub-detectors (TPC, PHOS, FMD and EMCal), utilize a BusyBox to keep track of free buffers in their Fec. The BusyBox asserts the busy signal to the LTU when one or more of these conditions are true: # Buffers in Fec are full # Upon receiving a trigger sequence from TTC # When the TTC sends a global reset to the Fee The busy signal is de-asserted when one or more FEC buffers are freed The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 7506d260888c07260fd40c79dcda2597ea83fff2 540 539 2009-05-20T12:39:23Z Rbo021 13 wikitext text/x-wiki == Overview == ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 7f83348161b132ab7b0118a3ea22950e0562dd57 541 540 2009-05-20T12:41:28Z Rbo021 13 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 64f0898eb12df58932e26b417cd538b2f09623db 543 541 2009-05-20T12:45:26Z Rbo021 13 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|500px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] ed761df9e1417f2ceca4ffa30a063995f3e44e97 544 543 2009-05-20T12:46:12Z Rbo021 13 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 2b8d8a33ef5dbf9dcebf3864daff4b04a06eb4d1 545 544 2009-05-20T12:57:02Z Dfe002 7 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === [[How to run the RCU - DRORC - Busybox setup]] === === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> '''1.01 (~may 2009)''' <br> <ul> <li> Firmware version register added to 0x2015 </li> <li> Busy Controller module updated to handle orphan messages </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1.bit busybox_fpga1.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga2.bit busybox_fpga2.bit] | [http://svn.ift.uib.no/svn/busybox_firmware/trunk/busybox_files/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 140a90d6b1fed31a4ad403d281748f334e513233 6 185 506 2009-05-20T11:26:11Z Rbo021 13 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 186 542 2009-05-20T12:44:30Z Rbo021 13 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 187 546 2009-05-20T13:07:31Z Dfe002 7 Created page with '=== How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collect...' wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. ## Configure the RCU with the conf-rcu alias. This sets up the RCU and configures the Front End Cards (FECs). ### Execute the /etc/boot/S40... script on the RCU-DCS. This changes the trigger from a software trigger to the DCS trigger intput. #### Start the infoBrowser on the drorc machine with the command "infoBrowser". ##### Start date with the command "startdate". ###### Log into the LTU: "ssh -X ltu@vme1". This is the general setup and configuration done. Continue with the the setup of the LTU. = RCU stuff = = LTU stuff = = Busybox stuff = = Datataking with date = 17788a5c086aed37782e6c444cc5cfec7a04f1b3 547 546 2009-05-20T13:08:09Z Dfe002 7 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Configure the RCU with the conf-rcu alias. This sets up the RCU and configures the Front End Cards (FECs). # Execute the /etc/boot/S40... script on the RCU-DCS. This changes the trigger from a software trigger to the DCS trigger intput. # Start the infoBrowser on the drorc machine with the command "infoBrowser". # Start date with the command "startdate". # Log into the LTU: "ssh -X ltu@vme1". This is the general setup and configuration done. Continue with the the setup of the LTU. = RCU stuff = = LTU stuff = = Busybox stuff = = Datataking with date = 1d984f3de8816ac01b7e6e65a352db1cb341751b 0 3 548 545 2009-05-24T19:26:04Z Rbo021 13 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === [[How to run the RCU - DRORC - Busybox setup]] === === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 0cfac96c7e8ae58fdc29674094f339700723adf8 0 187 554 547 2009-05-29T06:52:12Z Dfe002 7 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Log into the LTU: "ssh -X ltu@vme1". # Log into the RCU dcs board: "ssh dcs0031". # Log into the Busybox DCS board: "ssh dcs0055". # Start the infoBrowser on the drorc machine with the command "infoBrowser". = Configuring the RCU = On the RCU, execute the script /etc/boot/S40configure.sh. This does several things: - turning on the Front End Cards - Setting the correct L2 Latency - Switching to LTU trigger Then, as the date user from the drorc machine, execute the alias 'conf-fec'. This configures the RCU and FECs via the DDL for Data readout, but unfortunately also for Software triggers. Therefor, execute the S40configure.sh script on the dcs0031 once again. = LTU stuff = On the LTU, execute 'vmecrate ltu'. This should pop up two windows on your machine. In the ltu window, click on Configuration-> TTCInit, and then Configuration->LTUInit. Click on 'CTP Emulator' to open the CTP Emulator window. Click on 'click here to choose sequence', and choose the 'L2a.seq'. Don't forget to click 'Load sequence'. Sending triggers: After you clicked on 'start emulation' you can send triggers in two ways: - Single triggers, for this just click on 'Generate SW Start signal(s)'. - Or triggers with a certain rate. For this, click on 'not selected' and choose BC. You can switch the BC downscaling hex value to a decimal value by right clicking on the value. Rates can also be entered in a more convenient manner than the downscaling factor: <blockquote style="background-color: lightgrey; border: solid thin grey;"> BC downscaling factor is an integer number (32 bits) giving the number of BCs (25ns) between 2 triggers. Examples: 0 -> BC rate (40 Mhz) 1 -> 40/2 Mhz rate 4000-> generate 1 Start signal per 100 micsecs ... or use: s (seconds, ms (miliseconds, us (microseconds), for period or: hz (hertz), khz (kilohertz), mhz (megahertz) for rate. 3s -> 3 seconds 10 ms -> 10 miliseconds period 3 khz -> 3 khz rate </blockquote> = Busybox stuff = = Datataking with date = 528301c780d3c834134bf68aabe7f85c5daefa90 555 554 2009-05-29T07:04:38Z Dfe002 7 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Log into the LTU: "ssh -X ltu@vme1". # Log into the RCU dcs board: "ssh dcs0031". # Log into the Busybox DCS board: "ssh dcs0055". # Start the infoBrowser on the drorc machine with the command "infoBrowser". = Configuring the RCU = On the RCU, execute the script /etc/boot/S40configure.sh. This does several things: - turning on the Front End Cards - Setting the correct L2 Latency - Switching to LTU trigger Then, as the date user from the drorc machine, execute the alias 'conf-fec'. This configures the RCU and FECs via the DDL for Data readout, but unfortunately also for Software triggers. Therefor, execute the S40configure.sh script on the dcs0031 once again. = LTU stuff = On the LTU, execute 'vmecrate ltu'. This should pop up two windows on your machine. In the ltu window, click on Configuration-> TTCInit, and then Configuration->LTUInit. Click on 'CTP Emulator' to open the CTP Emulator window. Click on 'click here to choose sequence', and choose the 'L2a.seq'. Don't forget to click 'Load sequence'. Sending triggers: After you clicked on 'start emulation' you can send triggers in two ways: - Single triggers, for this just click on 'Generate SW Start signal(s)'. - Or triggers with a certain rate. For this, click on 'not selected' and choose BC. You can switch the BC downscaling hex value to a decimal value by right clicking on the value. Rates can also be entered in a more convenient manner than the downscaling factor: <blockquote style="background-color: lightgrey; border: solid thin grey;"> BC downscaling factor is an integer number (32 bits) giving the number of BCs (25ns) between 2 triggers.<br> Examples:<br> 0 -> BC rate (40 Mhz)<br> 1 -> 40/2 Mhz rate<br> 4000-> generate 1 Start signal per 100 micsecs<br> ...<br><br> or use: s (seconds, ms (miliseconds, us (microseconds), for period or:<br> hz (hertz), khz (kilohertz), mhz (megahertz) for rate.<br> 3s -> 3 seconds<br> 10 ms -> 10 miliseconds period<br> 3 khz -> 3 khz rate<br> </blockquote> = Busybox stuff = From the busybox DCS board, you find some bitfiles to program and setup the Busybox under: /mnt/kjekspc7/rbo021/busybox_files. You can program the busybox with the program.sh script: ./program.sh busybox_fpga1.bit busybox_fpga2.bit If you ommit the second bitfile, a dummy bitfile is used and only 1 FPGA programmed. = Datataking with date = #Start date from the drorc machine as date user with the command: 'startdate'. #Take the lock by clicking on the white open lock symbol. #Click on the right arrows until the 'Ready to start' is highlighted, and the button underneath is clickable. #Click on Start processes. On the LDC display, the green icon should move down to the point 'Waiting start of data', and the LDC status display should reset its numbers, then show 2 Sub-events recorded. These are the Start of Run Events. #Then press start. #You then can send triggers from the LTU with the CTP emulator. #The procedure is always: Start run, Start sending triggers, Stop sending triggers, Stop run. If you send triggers while there is no run, the Events remain in the RCU and are not being read out, which makes the run the stuck and the RCU will have to be reset. The Busybox has to be reset between each run anyway with the bbinit.sh script. 028a022211f341fd320b2f7cd72cddcfea18b85e 556 555 2009-05-29T07:05:16Z Dfe002 7 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Log into the LTU: "ssh -X ltu@vme1". # Log into the RCU dcs board: "ssh dcs0031". # Log into the Busybox DCS board: "ssh dcs0055". # Start the infoBrowser on the drorc machine with the command "infoBrowser". = Configuring the RCU = On the RCU, execute the script /etc/boot/S40configure.sh. This does several things: - turning on the Front End Cards - Setting the correct L2 Latency - Switching to LTU trigger Then, as the date user from the drorc machine, execute the alias 'conf-fec'. This configures the RCU and FECs via the DDL for Data readout, but unfortunately also for Software triggers. Therefor, execute the S40configure.sh script on the dcs0031 once again. = LTU stuff = On the LTU, execute 'vmecrate ltu'. This should pop up two windows on your machine. In the ltu window, click on Configuration-> TTCInit, and then Configuration->LTUInit. Click on 'CTP Emulator' to open the CTP Emulator window. Click on 'click here to choose sequence', and choose the 'L2a.seq'. Don't forget to click 'Load sequence'. Sending triggers: After you clicked on 'start emulation' you can send triggers in two ways: - Single triggers, for this just click on 'Generate SW Start signal(s)'. - Or triggers with a certain rate. For this, click on 'not selected' and choose BC. You can switch the BC downscaling hex value to a decimal value by right clicking on the value. Rates can also be entered in a more convenient manner than the downscaling factor: <blockquote style="background-color: lightgrey; border: solid thin grey;"> BC downscaling factor is an integer number (32 bits) giving the number of BCs (25ns) between 2 triggers.<br> Examples:<br> 0 -> BC rate (40 Mhz)<br> 1 -> 40/2 Mhz rate<br> 4000-> generate 1 Start signal per 100 micsecs<br> ...<br><br> or use: s (seconds, ms (miliseconds, us (microseconds), for period or:<br> hz (hertz), khz (kilohertz), mhz (megahertz) for rate.<br> 3s -> 3 seconds<br> 10 ms -> 10 miliseconds period<br> 3 khz -> 3 khz rate<br> </blockquote> = Busybox stuff = From the busybox DCS board, you find some bitfiles to program and setup the Busybox under: /mnt/kjekspc7/rbo021/busybox_files. You can program the busybox with the program.sh script: ./program.sh busybox_fpga1.bit busybox_fpga2.bit If you ommit the second bitfile, a dummy bitfile is used and only 1 FPGA programmed. = Datataking with date = #Start date from the drorc machine as date user with the command: 'startdate'. #Take the lock by clicking on the white open lock symbol. #Click on the right arrows until the 'Ready to start' is highlighted, and the button underneath is clickable. #Click on Start processes. On the LDC display, the green icon should move down to the point 'Waiting start of data', and the LDC status display should reset its numbers, then show 2 Sub-events recorded. These are the Start of Run Events. #Then press start. #You then can send triggers from the LTU with the CTP emulator. #The procedure is always: Start run, Start sending triggers, Stop sending triggers, Stop run.If you send triggers while there is no run, the Events remain in the RCU and are not being read out, which makes the run the stuck and the RCU will have to be reset. The Busybox has to be reset between each run anyway with the bbinit.sh script. 8cc014d08a54c65ecd9cd6c1e940eb865b1f9cac 557 556 2009-05-29T07:34:59Z Dfe002 7 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Log into the LTU: "ssh -X ltu@vme1". # Log into the RCU dcs board: "ssh dcs0031". # Log into the Busybox DCS board: "ssh dcs0055". # Start the infoBrowser on the drorc machine with the command "infoBrowser". = Configuring the RCU = On the RCU, execute the script /etc/boot/S40configure.sh. This does several things: - turning on the Front End Cards - Setting the correct L2 Latency - Switching to LTU trigger Then, as the date user from the drorc machine, execute the alias 'conf-fec'. This configures the RCU and FECs via the DDL for Data readout, but unfortunately also for Software triggers. Therefor, execute the S40configure.sh script on the dcs0031 once again. = LTU stuff = On the LTU, execute 'vmecrate ltu'. This should pop up two windows on your machine. In the ltu window, click on Configuration-> TTCInit, and then Configuration->LTUInit. Click on 'CTP Emulator' to open the CTP Emulator window. Click on 'click here to choose sequence', and choose the 'L2a.seq'. Don't forget to click 'Load sequence'. Sending triggers: After you clicked on 'start emulation' you can send triggers in two ways: - Single triggers, for this just click on 'Generate SW Start signal(s)'. - Or triggers with a certain rate. For this, click on 'not selected' and choose BC. You can switch the BC downscaling hex value to a decimal value by right clicking on the value. Rates can also be entered in a more convenient manner than the downscaling factor: <blockquote style="background-color: lightgrey; border: solid thin grey;"> BC downscaling factor is an integer number (32 bits) giving the number of BCs (25ns) between 2 triggers.<br> Examples:<br> 0 -> BC rate (40 Mhz)<br> 1 -> 40/2 Mhz rate<br> 4000-> generate 1 Start signal per 100 micsecs<br> ...<br><br> or use: s (seconds, ms (miliseconds, us (microseconds), for period or:<br> hz (hertz), khz (kilohertz), mhz (megahertz) for rate.<br> 3s -> 3 seconds<br> 10 ms -> 10 miliseconds period<br> 3 khz -> 3 khz rate<br> </blockquote> After each change of this value, you have to press Enter (or move the mouse cursor out of the testbox). You can see the changed value in the status window. = Busybox stuff = From the busybox DCS board, you find some bitfiles to program and setup the Busybox under: /mnt/kjekspc7/rbo021/busybox_files. You can program the busybox with the program.sh script: ./program.sh busybox_fpga1.bit busybox_fpga2.bit If you ommit the second bitfile, a dummy bitfile is used and only 1 FPGA programmed. = Datataking with date = #Start date from the drorc machine as date user with the command: 'startdate'. #Take the lock by clicking on the white open lock symbol. #Click on the right arrows until the 'Ready to start' is highlighted, and the button underneath is clickable. #Click on Start processes. On the LDC display, the green icon should move down to the point 'Waiting start of data', and the LDC status display should reset its numbers, then show 2 Sub-events recorded. These are the Start of Run Events. #Then press start. #You then can send triggers from the LTU with the CTP emulator. #The procedure is always: Start run, Start sending triggers, Stop sending triggers, Stop run.If you send triggers while there is no run, the Events remain in the RCU and are not being read out, which makes the run the stuck and the RCU will have to be reset. The Busybox has to be reset between each run anyway with the bbinit.sh script. Always make sure to release the lock before you close date, otherwise the drorc machine has to be rebooted. =FAQ= ===The Date/LTU Window don't open=== Make sure you have the '-X' in the ssh command. ===The lock in date is red and I can't take it=== Someone else has date opened and has the lock, or date was closed without releasing the lock first. Reboot the date machine. ===There is an error message '1146' in the InfoBrowser=== That's normal. ===I want to see older messages in the InfoBrowser=== Unhighlight the 'Online' on the lower right side, then press 'Query'. ===How can I add another drorc equipment?=== editDb on the drorc machine. ===How is the physmem on the drorc machine set up?=== -alonegdc ipc 1000000 control,eventbuilder 2 -aloneldc ipc 1048756 control,readoutReadyFifo 1 -aloneldc ipc 1048756 readout 3 -aloneldc ipc 1048756 readoutFirstLevelVectors 4 -aloneldc ipc 1048756 readoutSecondLevelVectors 6 -aloneldc physmem /dev/physmem1 524288000 readoutDataPages 7 ===Which equipements are needed?=== drorc3006_0 -EqId: 2 -rorcRevision: 3 -rorcSerialNb: 3006 -rorcChannelNb: 0 -dataSource: 0 (Fec) -mrorcId: 7 (for this one) drorc_trigger a2f153b581659048cbb7587bfb2d4a2c09b1fdfd 558 557 2009-05-29T07:37:12Z Dfe002 7 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Log into the LTU: "ssh -X ltu@vme1". # Log into the RCU dcs board: "ssh dcs0031". # Log into the Busybox DCS board: "ssh dcs0055". # Start the infoBrowser on the drorc machine with the command "infoBrowser". = Configuring the RCU = On the RCU, execute the script /etc/boot/S40configure.sh. This does several things: - turning on the Front End Cards - Setting the correct L2 Latency - Switching to LTU trigger Then, as the date user from the drorc machine, execute the alias 'conf-fec'. This configures the RCU and FECs via the DDL for Data readout, but unfortunately also for Software triggers. Therefor, execute the S40configure.sh script on the dcs0031 once again. = LTU stuff = On the LTU, execute 'vmecrate ltu'. This should pop up two windows on your machine. In the ltu window, click on Configuration-> TTCInit, and then Configuration->LTUInit. Click on 'CTP Emulator' to open the CTP Emulator window. Click on 'click here to choose sequence', and choose the 'L2a.seq'. Don't forget to click 'Load sequence'. Sending triggers: After you clicked on 'start emulation' you can send triggers in two ways: - Single triggers, for this just click on 'Generate SW Start signal(s)'. - Or triggers with a certain rate. For this, click on 'not selected' and choose BC. You can switch the BC downscaling hex value to a decimal value by right clicking on the value. Rates can also be entered in a more convenient manner than the downscaling factor: <blockquote style="background-color: lightgrey; border: solid thin grey;"> BC downscaling factor is an integer number (32 bits) giving the number of BCs (25ns) between 2 triggers.<br> Examples:<br> 0 -> BC rate (40 Mhz)<br> 1 -> 40/2 Mhz rate<br> 4000-> generate 1 Start signal per 100 micsecs<br> ...<br><br> or use: s (seconds, ms (miliseconds, us (microseconds), for period or:<br> hz (hertz), khz (kilohertz), mhz (megahertz) for rate.<br> 3s -> 3 seconds<br> 10 ms -> 10 miliseconds period<br> 3 khz -> 3 khz rate<br> </blockquote> After each change of this value, you have to press Enter (or move the mouse cursor out of the testbox). You can see the changed value in the status window. = Busybox stuff = From the busybox DCS board, you find some bitfiles to program and setup the Busybox under: /mnt/kjekspc7/rbo021/busybox_files. You can program the busybox with the program.sh script: ./program.sh busybox_fpga1.bit busybox_fpga2.bit If you ommit the second bitfile, a dummy bitfile is used and only 1 FPGA programmed. = Datataking with date = #Start date from the drorc machine as date user with the command: 'startdate'. #Take the lock by clicking on the white open lock symbol. #Click on the right arrows until the 'Ready to start' is highlighted, and the button underneath is clickable. #Click on Start processes. On the LDC display, the green icon should move down to the point 'Waiting start of data', and the LDC status display should reset its numbers, then show 2 Sub-events recorded. These are the Start of Run Events. #Then press start. #You then can send triggers from the LTU with the CTP emulator. #The procedure is always: Start run, Start sending triggers, Stop sending triggers, Stop run.If you send triggers while there is no run, the Events remain in the RCU and are not being read out, which makes the run the stuck and the RCU will have to be reset. The Busybox has to be reset between each run anyway with the bbinit.sh script. Always make sure to release the lock before you close date, otherwise the drorc machine has to be rebooted. =FAQ= ===The Date/LTU Window don't open=== Make sure you have the '-X' in the ssh command. ===The lock in date is red and I can't take it=== Someone else has date opened and has the lock, or date was closed without releasing the lock first. Reboot the date machine. ===There is an error message '1146' in the InfoBrowser=== That's normal. ===I want to see older messages in the InfoBrowser=== Unhighlight the 'Online' on the lower right side, then press 'Query'. ===How can I add another drorc equipment?=== editDb on the drorc machine. ===How is the physmem on the drorc machine set up?=== *alonegdc ipc 1000000 control,eventbuilder 2 *aloneldc ipc 1048756 control,readoutReadyFifo 1 *aloneldc ipc 1048756 readout 3 *aloneldc ipc 1048756 readoutFirstLevelVectors 4 *aloneldc ipc 1048756 readoutSecondLevelVectors 6 *aloneldc physmem /dev/physmem1 524288000 readoutDataPages 7 ===Which equipements are needed?=== drorc3006_0 *EqId: 2 *rorcRevision: 3 *rorcSerialNb: 3006 *rorcChannelNb: 0 *dataSource: 0 (Fec) *mrorcId: 7 (for this one) drorc_trigger 7e29ac1bd77c0313a50fdba95ee9a8436a309c3d 559 558 2009-05-29T07:58:31Z Dfe002 7 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Log into the LTU: "ssh -X ltu@vme1". # Log into the RCU dcs board: "ssh dcs0031". # Log into the Busybox DCS board: "ssh dcs0055". # Start the infoBrowser on the drorc machine with the command "infoBrowser". = Configuring the RCU = On the RCU, execute the script /etc/boot/S40configure.sh. This does several things: - turning on the Front End Cards - Setting the correct L2 Latency - Switching to LTU trigger Then, as the date user from the drorc machine, execute the alias 'conf-fec'. This configures the RCU and FECs via the DDL for Data readout, but unfortunately also for Software triggers. Therefor, execute the S40configure.sh script on the dcs0031 once again. = LTU stuff = On the LTU, execute 'vmecrate ltu'. This should pop up two windows on your machine. In the ltu window, click on Configuration-> TTCInit, and then Configuration->LTUInit. Click on 'CTP Emulator' to open the CTP Emulator window. Click on 'click here to choose sequence', and choose the 'L2a.seq'. Don't forget to click 'Load sequence'. Sending triggers: After you clicked on 'start emulation' you can send triggers in two ways: - Single triggers, for this just click on 'Generate SW Start signal(s)'. - Or triggers with a certain rate. For this, click on 'not selected' and choose BC. You can switch the BC downscaling hex value to a decimal value by right clicking on the value. Rates can also be entered in a more convenient manner than the downscaling factor: <blockquote style="background-color: lightgrey; border: solid thin grey;"> BC downscaling factor is an integer number (32 bits) giving the number of BCs (25ns) between 2 triggers.<br> Examples:<br> 0 -> BC rate (40 Mhz)<br> 1 -> 40/2 Mhz rate<br> 4000-> generate 1 Start signal per 100 micsecs<br> ...<br><br> or use: s (seconds, ms (miliseconds, us (microseconds), for period or:<br> hz (hertz), khz (kilohertz), mhz (megahertz) for rate.<br> 3s -> 3 seconds<br> 10 ms -> 10 miliseconds period<br> 3 khz -> 3 khz rate<br> </blockquote> After each change of this value, you have to press Enter (or move the mouse cursor out of the testbox). You can see the changed value in the status window. = Busybox stuff = From the busybox DCS board, you find some bitfiles to program and setup the Busybox under: /mnt/kjekspc7/rbo021/busybox_files. You can program the busybox with the program.sh script: ./program.sh busybox_fpga1.bit busybox_fpga2.bit If you ommit the second bitfile, a dummy bitfile is used and only 1 FPGA programmed. = Datataking with date = #Start date from the drorc machine as date user with the command: 'startdate'. #Take the lock by clicking on the white open lock symbol. #Click on the right arrows until the 'Ready to start' is highlighted, and the button underneath is clickable. #Click on Start processes. On the LDC display, the green icon should move down to the point 'Waiting start of data', and the LDC status display should reset its numbers, then show 2 Sub-events recorded. These are the Start of Run Events. #Then press start. #You then can send triggers from the LTU with the CTP emulator. #The procedure is always: Start run, Start sending triggers, Stop sending triggers, Stop run.If you send triggers while there is no run, the Events remain in the RCU and are not being read out, which makes the run the stuck and the RCU will have to be reset. The Busybox has to be reset between each run anyway with the bbinit.sh script. Always make sure to release the lock before you close date, otherwise the drorc machine has to be rebooted. =FAQ= ===The Date/LTU Window don't open=== Make sure you have the '-X' in the ssh command. ===The lock in date is red and I can't take it=== Someone else has date opened and has the lock, or date was closed without releasing the lock first. Reboot the date machine. ===There is an error message '1146' in the InfoBrowser=== That's normal. ===I want to see older messages in the InfoBrowser=== Unhighlight the 'Online' on the lower right side, then press 'Query'. ===How can I add another drorc equipment?=== editDb on the drorc machine. After changing the database, you have to go back to the 'Disconnected Configuration' in the DAQ RunControl for the new values to get fetched from the database. ===How is the physmem on the drorc machine set up?=== *alonegdc ipc 1000000 control,eventbuilder 2 *aloneldc ipc 1048756 control,readoutReadyFifo 1 *aloneldc ipc 1048756 readout 3 *aloneldc ipc 1048756 readoutFirstLevelVectors 4 *aloneldc ipc 1048756 readoutSecondLevelVectors 6 *aloneldc physmem /dev/physmem1 524288000 readoutDataPages 7 ===Which equipements are needed?=== drorc3006_0 *EqId: 2 *rorcRevision: 3 *rorcSerialNb: 3006 *rorcChannelNb: 0 *dataSource: 0 (Fec) *mrorcId: 7 (for this one) drorc_trigger c7071019984ce9e0fbdb23028d5d6d1d3dc75c8e 640 559 2009-08-21T14:28:52Z Nfyku 4 wikitext text/x-wiki === How to run the RCU - DRORC - Busybox setup === This shall be a step by step introduction on how to operate the setup and test Busybox firmware. For now this will be a collection of the necessary steps, but in a later stage the configuration part will become more automated. You need access to the following systems: - DRORC PC - RCU - Busybox - Local trigger unit (LTU) Setting up the system and getting ready to take data: = More general stuff = # Log into the Drorc machine as the date user. # Log into the LTU: "ssh -X ltu@vme1". # Log into the RCU dcs board: "ssh dcs0031". # Log into the Busybox DCS board: "ssh dcs0055". # Start the infoBrowser on the drorc machine with the command "infoBrowser". = Configuring the RCU = On the RCU, execute the script /etc/boot/S40configure.sh. This does several things: - turning on the Front End Cards - Setting the correct L2 Latency - Switching to LTU trigger Then, as the date user from the drorc machine, execute the alias 'conf-fec'. This configures the RCU and FECs via the DDL for Data readout, but unfortunately also for Software triggers. Therefore, execute the S40configure.sh script on the dcs0031 once again. = LTU stuff = On the LTU, execute 'vmecrate ltu'. This should pop up two windows on your machine. In the ltu window, click on Configuration-> TTCInit, and then Configuration->LTUInit. Click on 'CTP Emulator' to open the CTP Emulator window. Click on 'click here to choose sequence', and choose the 'L2a.seq'. Don't forget to click 'Load sequence'. Sending triggers: After you clicked on 'start emulation' you can send triggers in two ways: - Single triggers, for this just click on 'Generate SW Start signal(s)'. - Or triggers with a certain rate. For this, click on 'not selected' and choose BC. You can switch the BC downscaling hex value to a decimal value by right clicking on the value. Rates can also be entered in a more convenient manner than the downscaling factor: <blockquote style="background-color: lightgrey; border: solid thin grey;"> BC downscaling factor is an integer number (32 bits) giving the number of BCs (25ns) between 2 triggers.<br> Examples:<br> 0 -> BC rate (40 Mhz)<br> 1 -> 40/2 Mhz rate<br> 4000-> generate 1 Start signal per 100 micsecs<br> ...<br><br> or use: s (seconds, ms (miliseconds, us (microseconds), for period or:<br> hz (hertz), khz (kilohertz), mhz (megahertz) for rate.<br> 3s -> 3 seconds<br> 10 ms -> 10 miliseconds period<br> 3 khz -> 3 khz rate<br> </blockquote> After each change of this value, you have to press Enter (or move the mouse cursor out of the testbox). You can see the changed value in the status window. = Busybox stuff = From the busybox DCS board, you find some bitfiles to program and setup the Busybox under: /mnt/kjekspc7/rbo021/busybox_files. You can program the busybox with the program.sh script: ./program busybox_fpga1.bit busybox_fpga2.bit If you omit the second bitfile, a dummy bitfile is used and only 1 FPGA programmed. = Datataking with date = #Start date from the drorc machine as date user with the command: 'startdate'. #Take the lock by clicking on the white open lock symbol. #Click on the right arrows until the 'Ready to start' is highlighted, and the button underneath is clickable. #Click on Start processes. On the LDC display, the green icon should move down to the point 'Waiting start of data', and the LDC status display should reset its numbers, then show 2 Sub-events recorded. These are the Start of Run Events. #Then press start. #You then can send triggers from the LTU with the CTP emulator. #The procedure is always: Start run, Start sending triggers, Stop sending triggers, Stop run.If you send triggers while there is no run, the Events remain in the RCU and are not being read out, which makes the run the stuck and the RCU will have to be reset. The Busybox has to be reset between each run anyway with the bbinit.sh script. Always make sure to release the lock before you close date, otherwise the drorc machine has to be rebooted. =FAQ= ===The Date/LTU Window don't open=== Make sure you have the '-X' in the ssh command. ===The lock in date is red and I can't take it=== Someone else has date opened and has the lock, or date was closed without releasing the lock first. Reboot the date machine. ===There is an error message '1146' in the InfoBrowser=== That's normal. ===I want to see older messages in the InfoBrowser=== Unhighlight the 'Online' on the lower right side, then press 'Query'. ===How can I add another drorc equipment?=== editDb on the drorc machine. After changing the database, you have to go back to the 'Disconnected Configuration' in the DAQ RunControl for the new values to get fetched from the database. ===How is the physmem on the drorc machine set up?=== *alonegdc ipc 1000000 control,eventbuilder 2 *aloneldc ipc 1048756 control,readoutReadyFifo 1 *aloneldc ipc 1048756 readout 3 *aloneldc ipc 1048756 readoutFirstLevelVectors 4 *aloneldc ipc 1048756 readoutSecondLevelVectors 6 *aloneldc physmem /dev/physmem1 524288000 readoutDataPages 7 ===Which equipements are needed?=== drorc3006_0 *EqId: 2 *rorcRevision: 3 *rorcSerialNb: 3006 *rorcChannelNb: 0 *dataSource: 0 (Fec) *mrorcId: 7 (for this one) drorc_trigger 69c865a817fab575515b7b459e73041bab58bc76 2 188 566 2009-06-04T09:21:48Z Tbu082 19 Created page with 'Peter Rosendahl' wikitext text/x-wiki Peter Rosendahl d2ffb7430c4148ff264299d8f8a262ed1427438f 0 25 567 460 2009-06-05T13:04:07Z St12361 17 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]] XJTAG Demo Board Tutorial Files and Instructions * [[PHYS321]] Øvingsoppgaver i PHYS321 [[Category:Mikroelektronikk]] 66d457667951c554e49a2fda19a01b1db91cfeb9 572 567 2009-06-05T13:27:24Z St12361 17 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[PHYS321]] Øvingsoppgaver i PHYS321 [[Category:Mikroelektronikk]] 7cfa3b9e29c6327915f4b5f355515656770ecdd4 646 572 2009-08-24T08:24:05Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[PHYS222]] Fagressurser for PHYS222 * [[PHYS321]] Øvingsoppgaver i PHYS321 [[Category:Mikroelektronikk]] 42d5810b55b888c6041a304ec59eb0027fe6e5a7 0 189 568 2009-06-05T13:13:49Z St12361 17 Created page with 'This concerns users running latest version of XJTAG SW with the XJ-Tag Demo Board v 1.2. Latest version of XJ-TAG SW is avaliable on request at: [http://www.XJTAG.com XJTAG.com]...' wikitext text/x-wiki This concerns users running latest version of XJTAG SW with the XJ-Tag Demo Board v 1.2. Latest version of XJ-TAG SW is avaliable on request at: [http://www.XJTAG.com XJTAG.com] The example files and tutorial that accompanies new versions of the XJ-TAG SW is not fully compatible with the XJ-TAG Demo board labeled v 1.2 that is avaliable at IFT. All original files for the XJTAG Demo Board v 1.2 is zipped in this file: [[File:XJTAG-DB-1_2.zip]] 992738d97d8ee5be4e93a7c78f89e386136c67af 569 568 2009-06-05T13:21:33Z St12361 17 wikitext text/x-wiki This concerns users running latest version of XJTAG SW with the XJ-Tag Demo Board v 1.2. Latest version of XJ-TAG SW is avaliable on request at: [http://www.XJTAG.com XJTAG.com] The example files and tutorial that accompanies new versions of the XJ-TAG SW is not fully compatible with the XJ-TAG Demo board labeled v 1.2 that is avaliable at IFT. First of all the Netlist must be exchanged with the original. Download netlist for v1.2 of the Demo Board here: [[File:Demo.Net.txt]] aff8d8e7aae28bea4c52f62ddffec2a245684717 570 569 2009-06-05T13:26:16Z St12361 17 wikitext text/x-wiki This concerns users running latest version of XJTAG SW with the XJ-Tag Demo Board v 1.2. Latest version of XJ-TAG SW is avaliable on request at: [http://www.XJTAG.com XJTAG.com] The example files and tutorial that accompanies new versions of the XJ-TAG SW is not fully compatible with the XJ-TAG Demo board labeled v 1.2 that is avaliable at IFT. First of all the Netlist must be exchanged with the original. Download netlist for v1.2 of the Demo Board here: * [[Demo.Net]] XJTAG Demo Board Tutorial Files and Instructions 38e3e56a8eb388445b06f5878451a86953b3dab9 0 190 571 2009-06-05T13:26:38Z St12361 17 Created page with '.HEA .APP "Cadstar RINF Output - Version 2.3" .UNI INCH 1000.0 in .TYP FULL .JOB "XJTAGDEMOV3" .ADD_COM C1 "0805" .ATT_COM C1 "Supplier" "RE" .ATT_COM C1 "PCB Footprint" "0805"...' wikitext text/x-wiki .HEA .APP "Cadstar RINF Output - Version 2.3" .UNI INCH 1000.0 in .TYP FULL .JOB "XJTAGDEMOV3" .ADD_COM C1 "0805" .ATT_COM C1 "Supplier" "RE" .ATT_COM C1 "PCB Footprint" "0805" .ATT_COM C1 "timestamp" "000CFE8C" .ATT_COM C1 "Type" "Y5V 50V" .ATT_COM C1 "Source Package" "CAP NP" .ATT_COM C1 "Order Code" "71-1400" .ATT_COM C1 "Value" "100nF" .ADD_COM C10 "0805" .ATT_COM C10 "Supplier" "RE" .ATT_COM C10 "PCB Footprint" "0805" .ATT_COM C10 "timestamp" "000C1A25" .ATT_COM C10 "Type" "Y5V 50V" .ATT_COM C10 "Source Package" "CAP NP" .ATT_COM C10 "Order Code" "71-1395" .ATT_COM C10 "Value" "47nF" .ADD_COM C11 "0805" .ATT_COM C11 "Supplier" "RE" .ATT_COM C11 "PCB Footprint" "0805" .ATT_COM C11 "timestamp" "000C1A3D" .ATT_COM C11 "Type" "Y5V 50V" .ATT_COM C11 "Source Package" "CAP NP" .ATT_COM C11 "Order Code" "71-1395" .ATT_COM C11 "Value" "47nF" .ADD_COM C2 "0805" .ATT_COM C2 "Supplier" "RE" .ATT_COM C2 "PCB Footprint" "0805" .ATT_COM C2 "timestamp" "000CFC8A" .ATT_COM C2 "Type" "Y5V 50V" .ATT_COM C2 "Source Package" "CAP NP" .ATT_COM C2 "Order Code" "71-1395" .ATT_COM C2 "Value" "47nF" .ADD_COM C3 "2.5mm pitch 6.3mmdia" .ATT_COM C3 "Cost100" ".14" .ATT_COM C3 "Supplier" "Newsham" .ATT_COM C3 "PCB Footprint" "2.5mm pitch 6.3mmdia" .ATT_COM C3 "Cost1" "0.16" .ATT_COM C3 "timestamp" "0007DF6F" .ATT_COM C3 "Type" "Low ESR" .ATT_COM C3 "Source Package" "CAPACITOR POL" .ATT_COM C3 "Manu" "Rubycon" .ATT_COM C3 "Order Code" "768-080" .ATT_COM C3 "Value" "220uF10v" .ATT_COM C3 "Cost25" ".16" .ATT_COM C3 "Man Ref" "10ZL220M6.3X11" .ADD_COM C4 "0805" .ATT_COM C4 "Supplier" "RE" .ATT_COM C4 "PCB Footprint" "0805" .ATT_COM C4 "timestamp" "0007643A" .ATT_COM C4 "Type" "Y5V 50V" .ATT_COM C4 "Source Package" "CAP NP" .ATT_COM C4 "Order Code" "71-1395" .ATT_COM C4 "Value" "47nF" .ADD_COM C5 "0805" .ATT_COM C5 "Supplier" "RE" .ATT_COM C5 "PCB Footprint" "0805" .ATT_COM C5 "timestamp" "000311A9" .ATT_COM C5 "Type" "Y5V 50V" .ATT_COM C5 "Source Package" "CAP NP" .ATT_COM C5 "Order Code" "71-1395" .ATT_COM C5 "Value" "47nF" .ADD_COM C6 "0805" .ATT_COM C6 "Supplier" "RE" .ATT_COM C6 "PCB Footprint" "0805" .ATT_COM C6 "timestamp" "000311C1" .ATT_COM C6 "Type" "Y5V 50V" .ATT_COM C6 "Source Package" "CAP NP" .ATT_COM C6 "Order Code" "71-1395" .ATT_COM C6 "Value" "47nF" .ADD_COM C7 "0805" .ATT_COM C7 "Supplier" "RE" .ATT_COM C7 "PCB Footprint" "0805" .ATT_COM C7 "timestamp" "0002B06B" .ATT_COM C7 "Type" "Y5V 50V" .ATT_COM C7 "Source Package" "CAP NP" .ATT_COM C7 "Order Code" "71-1395" .ATT_COM C7 "Value" "47nF" .ADD_COM C8 "0805" .ATT_COM C8 "Supplier" "RE" .ATT_COM C8 "PCB Footprint" "0805" .ATT_COM C8 "timestamp" "0002B0FB" .ATT_COM C8 "Type" "Y5V 50V" .ATT_COM C8 "Source Package" "CAP NP" .ATT_COM C8 "Order Code" "71-1395" .ATT_COM C8 "Value" "47nF" .ADD_COM C9 "0805" .ATT_COM C9 "Supplier" "RE" .ATT_COM C9 "PCB Footprint" "0805" .ATT_COM C9 "timestamp" "0002B0C3" .ATT_COM C9 "Type" "Y5V 50V" .ATT_COM C9 "Source Package" "CAP NP" .ATT_COM C9 "Order Code" "71-1395" .ATT_COM C9 "Value" "47nF" .ADD_COM CN1 "20 Way RA Box header socket" .ATT_COM CN1 "Cost100" "0.695" .ATT_COM CN1 "Supplier" "RE" .ATT_COM CN1 "Cost1" "0.85" .ATT_COM CN1 "PCB Footprint" "20 Way RA Box header socket" .ATT_COM CN1 "timestamp" "0007EBB1" .ATT_COM CN1 "Source Package" "CON20A" .ATT_COM CN1 "Order Code" "22-4140" .ATT_COM CN1 "Value" "CON20A" .ADD_COM CN2 "2x2.54mm holes" .ATT_COM CN2 "Fitted" "nf" .ATT_COM CN2 "PCB Footprint" "2x2.54mm holes" .ATT_COM CN2 "timestamp" "000D429A" .ATT_COM CN2 "Source Package" "CON2" .ATT_COM CN2 "Value" "2pin" .ADD_COM CN3 "20way DIL" .ATT_COM CN3 "Cost100" "0.065" .ATT_COM CN3 "Supplier" "RE" .ATT_COM CN3 "Cost1" "0.11" .ATT_COM CN3 "PCB Footprint" "20way DIL" .ATT_COM CN3 "timestamp" "000C9077" .ATT_COM CN3 "Cost50" "0.07" .ATT_COM CN3 "Source Package" "DIL socket20way" .ATT_COM CN3 "Order Code" "22-0170" .ATT_COM CN3 "Value" "DIL socket20way" .ADD_COM D1 "SOT23" .ATT_COM D1 "Cost100" "0.11" .ATT_COM D1 "Supplier" "RE" .ATT_COM D1 "PCB Footprint" "SOT23" .ATT_COM D1 "timestamp" "000CC264" .ATT_COM D1 "Source Package" "LED BI-COLOUR_0" .ATT_COM D1 "Cost10" "0.15" .ATT_COM D1 "Manu" "KingBright" .ATT_COM D1 "Order Code" "72-8795" .ATT_COM D1 "Value" "Red/Green" .ATT_COM D1 "Man Ref" "KM23 series" .ADD_COM D2 "SOT23" .ATT_COM D2 "Cost100" "0.11" .ATT_COM D2 "Supplier" "RE" .ATT_COM D2 "PCB Footprint" "SOT23" .ATT_COM D2 "timestamp" "000CC122" .ATT_COM D2 "Source Package" "LED BI-COLOUR_0" .ATT_COM D2 "Cost10" "0.15" .ATT_COM D2 "Manu" "KingBright" .ATT_COM D2 "Order Code" "72-8795" .ATT_COM D2 "Value" "Red/Green" .ATT_COM D2 "Man Ref" "KM23 series" .ADD_COM D3 "SOT23" .ATT_COM D3 "Cost100" "0.11" .ATT_COM D3 "Supplier" "RE" .ATT_COM D3 "PCB Footprint" "SOT23" .ATT_COM D3 "timestamp" "000CBFE0" .ATT_COM D3 "Source Package" "LED BI-COLOUR_0" .ATT_COM D3 "Cost10" "0.15" .ATT_COM D3 "Manu" "KingBright" .ATT_COM D3 "Order Code" "72-8795" .ATT_COM D3 "Value" "Red/Green" .ATT_COM D3 "Man Ref" "KM23 series" .ADD_COM D4 "SOT23" .ATT_COM D4 "Cost100" "0.11" .ATT_COM D4 "Supplier" "RE" .ATT_COM D4 "PCB Footprint" "SOT23" .ATT_COM D4 "timestamp" "000CC340" .ATT_COM D4 "Source Package" "LED BI-COLOUR_0" .ATT_COM D4 "Cost10" "0.15" .ATT_COM D4 "Manu" "KingBright" .ATT_COM D4 "Order Code" "72-8795" .ATT_COM D4 "Value" "Red/Green" .ATT_COM D4 "Man Ref" "KM23 series" .ADD_COM D5 "SOT23" .ATT_COM D5 "Cost100" "0.11" .ATT_COM D5 "Supplier" "RE" .ATT_COM D5 "PCB Footprint" "SOT23" .ATT_COM D5 "timestamp" "000CC1FE" .ATT_COM D5 "Source Package" "LED BI-COLOUR_0" .ATT_COM D5 "Cost10" "0.15" .ATT_COM D5 "Manu" "KingBright" .ATT_COM D5 "Order Code" "72-8795" .ATT_COM D5 "Value" "Red/Green" .ATT_COM D5 "Man Ref" "KM23 series" .ADD_COM D6 "SOT23" .ATT_COM D6 "Cost100" "0.11" .ATT_COM D6 "Supplier" "RE" .ATT_COM D6 "PCB Footprint" "SOT23" .ATT_COM D6 "timestamp" "000CC0BC" .ATT_COM D6 "Source Package" "LED BI-COLOUR_0" .ATT_COM D6 "Cost10" "0.15" .ATT_COM D6 "Manu" "KingBright" .ATT_COM D6 "Order Code" "72-8795" .ATT_COM D6 "Value" "Red/Green" .ATT_COM D6 "Man Ref" "KM23 series" .ADD_COM D7 "SOT23" .ATT_COM D7 "Cost100" "0.11" .ATT_COM D7 "Supplier" "RE" .ATT_COM D7 "PCB Footprint" "SOT23" .ATT_COM D7 "timestamp" "000CC2BC" .ATT_COM D7 "Source Package" "LED BI-COLOUR_0" .ATT_COM D7 "Cost10" "0.15" .ATT_COM D7 "Manu" "KingBright" .ATT_COM D7 "Order Code" "72-8795" .ATT_COM D7 "Value" "Red/Green" .ATT_COM D7 "Man Ref" "KM23 series" .ADD_COM D8 "SOT23" .ATT_COM D8 "Cost100" "0.11" .ATT_COM D8 "Supplier" "RE" .ATT_COM D8 "PCB Footprint" "SOT23" .ATT_COM D8 "timestamp" "000CC17A" .ATT_COM D8 "Source Package" "LED BI-COLOUR_0" .ATT_COM D8 "Cost10" "0.15" .ATT_COM D8 "Manu" "KingBright" .ATT_COM D8 "Order Code" "72-8795" .ATT_COM D8 "Value" "Red/Green" .ATT_COM D8 "Man Ref" "KM23 series" .ADD_COM D9 "SOT23" .ATT_COM D9 "Cost100" "0.11" .ATT_COM D9 "Supplier" "RE" .ATT_COM D9 "PCB Footprint" "SOT23" .ATT_COM D9 "timestamp" "000CC038" .ATT_COM D9 "Source Package" "LED BI-COLOUR_0" .ATT_COM D9 "Cost10" "0.15" .ATT_COM D9 "Manu" "KingBright" .ATT_COM D9 "Order Code" "72-8795" .ATT_COM D9 "Value" "Red/Green" .ATT_COM D9 "Man Ref" "KM23 series" .ADD_COM IC1 "SO14" .ATT_COM IC1 "Supplier" "FEC" .ATT_COM IC1 "PCB Footprint" "SO14" .ATT_COM IC1 "timestamp" "000CFAD0" .ATT_COM IC1 "Source Package" "74HC04/SO" .ATT_COM IC1 "Order Code" "379-268" .ATT_COM IC1 "Value" "74HC14" .ADD_COM IC2 "CS48" .ATT_COM IC2 "Supplier" "Insight" .ATT_COM IC2 "PCB Footprint" "CS48" .ATT_COM IC2 "Cost1" "$0.99" .ATT_COM IC2 "timestamp" "000C8277" .ATT_COM IC2 "Source Package" "XC9536/VFP_1" .ATT_COM IC2 "Manu" "Xilinx" .ATT_COM IC2 "Man ref" "XC9536XL-10CS48C" .ATT_COM IC2 "Value" "XC9536XL" .ADD_COM IC3 "44 TQFP" .ATT_COM IC3 "Supplier" "Unique" .ATT_COM IC3 "PCB Footprint" "44 TQFP" .ATT_COM IC3 "timestamp" "000C89EA" .ATT_COM IC3 "Source Package" "EPM3032A" .ATT_COM IC3 "Value" "EPM3032A" .ADD_COM IC4 "SO8" .ATT_COM IC4 "Cost100" "0.45" .ATT_COM IC4 "Supplier" "FEC" .ATT_COM IC4 "PCB Footprint" "SO8" .ATT_COM IC4 "Cost1" "0.65" .ATT_COM IC4 "timestamp" "000854DF" .ATT_COM IC4 "Source Package" "24LC01B/SO" .ATT_COM IC4 "Manu" "Microchip" .ATT_COM IC4 "Cost10" "0.53" .ATT_COM IC4 "Order Code" "300-1647" .ATT_COM IC4 "Value" "24LC32A" .ATT_COM IC4 "Man Ref" "24LC32A/SN" .ADD_COM IC5 "SMT 24" .ATT_COM IC5 "Cost100" "0.8" .ATT_COM IC5 "Supplier" "FEC" .ATT_COM IC5 "PCB Footprint" "SMT 24" .ATT_COM IC5 "Cost1" "1.26" .ATT_COM IC5 "timestamp" "000C9105" .ATT_COM IC5 "Source Package" "HM6116" .ATT_COM IC5 "Manu" "HT" .ATT_COM IC5 "Cost10" ".96" .ATT_COM IC5 "Order Code" "115-861" .ATT_COM IC5 "Value" "HT6116" .ATT_COM IC5 "Man Ref" "HT6116-70S" .ADD_COM JP1 "4x2x2.54mm Holes" .ATT_COM JP1 "Cost100" "0.04" .ATT_COM JP1 "Supplier" "RE" .ATT_COM JP1 "PCB Footprint" "4x2x2.54mm Holes" .ATT_COM JP1 "Cost1" "0.06" .ATT_COM JP1 "timestamp" "000D3012" .ATT_COM JP1 "Source Package" "JUMPER4" .ATT_COM JP1 "Order Code" "22-0555" .ATT_COM JP1 "Value" "JUMPER4" .ADD_COM JP2 "4x2x2.54mm Holes" .ATT_COM JP2 "Cost100" "0.04" .ATT_COM JP2 "Supplier" "RE" .ATT_COM JP2 "PCB Footprint" "4x2x2.54mm Holes" .ATT_COM JP2 "Cost1" "0.06" .ATT_COM JP2 "timestamp" "000D3162" .ATT_COM JP2 "Source Package" "JUMPER4" .ATT_COM JP2 "Order Code" "22-0555" .ATT_COM JP2 "Value" "JUMPER4" .ADD_COM JP3 "4x2x2.54mm Holes" .ATT_COM JP3 "Cost100" "0.04" .ATT_COM JP3 "Supplier" "RE" .ATT_COM JP3 "PCB Footprint" "4x2x2.54mm Holes" .ATT_COM JP3 "Cost1" "0.06" .ATT_COM JP3 "timestamp" "000D2B1D" .ATT_COM JP3 "Source Package" "JUMPER4" .ATT_COM JP3 "Order Code" "22-0555" .ATT_COM JP3 "Value" "JUMPER4" .ADD_COM JP4 "10x1x2.54mm holes" .ATT_COM JP4 "Cost100" "0.04" .ATT_COM JP4 "Supplier" "RE" .ATT_COM JP4 "Cost1" "0.006" .ATT_COM JP4 "PCB Footprint" "10x1x2.54mm holes" .ATT_COM JP4 "timestamp" "000C97FA" .ATT_COM JP4 "Source Package" "JUMPER10_0" .ATT_COM JP4 "Order Code" "22-0515" .ATT_COM JP4 "Value" "JUMPhalf" .ADD_COM JP5 "10x2x 2.54mm holes" .ATT_COM JP5 "Cost100" "0.08" .ATT_COM JP5 "Supplier" "RE" .ATT_COM JP5 "Cost1" "0.12" .ATT_COM JP5 "PCB Footprint" "10x2x 2.54mm holes" .ATT_COM JP5 "timestamp" "000C95CE" .ATT_COM JP5 "Source Package" "JUMPER10" .ATT_COM JP5 "Order Code" "22-0565" .ATT_COM JP5 "Value" "JUMPER10" .ADD_COM JP6 "10x2x 2.54mm holes" .ATT_COM JP6 "Cost100" "0.08" .ATT_COM JP6 "Supplier" "RE" .ATT_COM JP6 "Cost1" "0.12" .ATT_COM JP6 "PCB Footprint" "10x2x 2.54mm holes" .ATT_COM JP6 "timestamp" "000C9EF3" .ATT_COM JP6 "Source Package" "JUMPER10" .ATT_COM JP6 "Order Code" "22-0565" .ATT_COM JP6 "Value" "JUMPER10" .ADD_COM JP7 "10x1x2.54mm holes" .ATT_COM JP7 "Cost100" "0.04" .ATT_COM JP7 "Supplier" "RE" .ATT_COM JP7 "Cost1" "0.006" .ATT_COM JP7 "PCB Footprint" "10x1x2.54mm holes" .ATT_COM JP7 "timestamp" "000CA363" .ATT_COM JP7 "Source Package" "JUMPER10_0" .ATT_COM JP7 "Order Code" "22-0515" .ATT_COM JP7 "Value" "JUMPhalf" .ADD_COM R1 "0805" .ATT_COM R1 "Cost100" "0.006" .ATT_COM R1 "Supplier" "RE" .ATT_COM R1 "PCB Footprint" "0805" .ATT_COM R1 "Cost1" "0.023" .ATT_COM R1 "timestamp" "000CFEB8" .ATT_COM R1 "Cost1000" "0.00710" .ATT_COM R1 "Pack" "100" .ATT_COM R1 "Source Package" "R" .ATT_COM R1 "Order Code" "72-0442" .ATT_COM R1 "Value" "10M" .ATT_COM R1 "Cost25" "0.023" .ADD_COM R10 "0805" .ATT_COM R10 "Cost100" "0.006" .ATT_COM R10 "Supplier" "RE" .ATT_COM R10 "PCB Footprint" "0805" .ATT_COM R10 "Cost1" "0.023" .ATT_COM R10 "timestamp" "000CC1DA" .ATT_COM R10 "Cost1000" "0.00710" .ATT_COM R10 "Pack" "100" .ATT_COM R10 "Source Package" "R" .ATT_COM R10 "Order Code" "72-4392" .ATT_COM R10 "Value" "120R" .ATT_COM R10 "Cost25" "0.023" .ADD_COM R11 "0805" .ATT_COM R11 "Cost100" "0.006" .ATT_COM R11 "Supplier" "RE" .ATT_COM R11 "PCB Footprint" "0805" .ATT_COM R11 "Cost1" "0.023" .ATT_COM R11 "timestamp" "000CC098" .ATT_COM R11 "Cost1000" "0.00710" .ATT_COM R11 "Pack" "100" .ATT_COM R11 "Source Package" "R" .ATT_COM R11 "Order Code" "72-4392" .ATT_COM R11 "Value" "120R" .ATT_COM R11 "Cost25" "0.023" .ADD_COM R12 "0805" .ATT_COM R12 "Cost100" "0.006" .ATT_COM R12 "Supplier" "RE" .ATT_COM R12 "PCB Footprint" "0805" .ATT_COM R12 "timestamp" "000DAEC9" .ATT_COM R12 "Pack" "100" .ATT_COM R12 "Source Package" "R" .ATT_COM R12 "Value" "8.2K" .ADD_COM R13 "0805" .ATT_COM R13 "Cost100" "0.006" .ATT_COM R13 "Supplier" "RE" .ATT_COM R13 "PCB Footprint" "0805" .ATT_COM R13 "timestamp" "000DAFE7" .ATT_COM R13 "Pack" "100" .ATT_COM R13 "Source Package" "R" .ATT_COM R13 "Value" "8.2K" .ADD_COM R14 "0805" .ATT_COM R14 "Cost100" "0.006" .ATT_COM R14 "Supplier" "RE" .ATT_COM R14 "PCB Footprint" "0805" .ATT_COM R14 "Cost1" "0.023" .ATT_COM R14 "timestamp" "000CC2A0" .ATT_COM R14 "Cost1000" "0.00710" .ATT_COM R14 "Pack" "100" .ATT_COM R14 "Source Package" "R" .ATT_COM R14 "Order Code" "72-4392" .ATT_COM R14 "Value" "120R" .ATT_COM R14 "Cost25" "0.023" .ADD_COM R15 "0805" .ATT_COM R15 "Cost100" "0.006" .ATT_COM R15 "Supplier" "RE" .ATT_COM R15 "PCB Footprint" "0805" .ATT_COM R15 "Cost1" "0.023" .ATT_COM R15 "timestamp" "000CC15E" .ATT_COM R15 "Cost1000" "0.00710" .ATT_COM R15 "Pack" "100" .ATT_COM R15 "Source Package" "R" .ATT_COM R15 "Order Code" "72-4392" .ATT_COM R15 "Value" "120R" .ATT_COM R15 "Cost25" "0.023" .ADD_COM R16 "0805" .ATT_COM R16 "Cost100" "0.006" .ATT_COM R16 "Supplier" "RE" .ATT_COM R16 "PCB Footprint" "0805" .ATT_COM R16 "Cost1" "0.023" .ATT_COM R16 "timestamp" "000CC01C" .ATT_COM R16 "Cost1000" "0.00710" .ATT_COM R16 "Pack" "100" .ATT_COM R16 "Source Package" "R" .ATT_COM R16 "Order Code" "72-4392" .ATT_COM R16 "Value" "120R" .ATT_COM R16 "Cost25" "0.023" .ADD_COM R17 "0805" .ATT_COM R17 "Cost100" "0.006" .ATT_COM R17 "Supplier" "RE" .ATT_COM R17 "PCB Footprint" "0805" .ATT_COM R17 "Cost1" "0.023" .ATT_COM R17 "timestamp" "000CC284" .ATT_COM R17 "Cost1000" "0.00710" .ATT_COM R17 "Pack" "100" .ATT_COM R17 "Source Package" "R" .ATT_COM R17 "Order Code" "72-4392" .ATT_COM R17 "Value" "120R" .ATT_COM R17 "Cost25" "0.023" .ADD_COM R18 "0805" .ATT_COM R18 "Cost100" "0.006" .ATT_COM R18 "Supplier" "RE" .ATT_COM R18 "PCB Footprint" "0805" .ATT_COM R18 "Cost1" "0.023" .ATT_COM R18 "timestamp" "000CC142" .ATT_COM R18 "Cost1000" "0.00710" .ATT_COM R18 "Pack" "100" .ATT_COM R18 "Source Package" "R" .ATT_COM R18 "Order Code" "72-4392" .ATT_COM R18 "Value" "120R" .ATT_COM R18 "Cost25" "0.023" .ADD_COM R19 "0805" .ATT_COM R19 "Cost100" "0.006" .ATT_COM R19 "Supplier" "RE" .ATT_COM R19 "PCB Footprint" "0805" .ATT_COM R19 "Cost1" "0.023" .ATT_COM R19 "timestamp" "000CC000" .ATT_COM R19 "Cost1000" "0.00710" .ATT_COM R19 "Pack" "100" .ATT_COM R19 "Source Package" "R" .ATT_COM R19 "Order Code" "72-4392" .ATT_COM R19 "Value" "120R" .ATT_COM R19 "Cost25" "0.023" .ADD_COM R2 "0805" .ATT_COM R2 "Cost100" "0.006" .ATT_COM R2 "Supplier" "RE" .ATT_COM R2 "PCB Footprint" "0805" .ATT_COM R2 "Cost1" "0.023" .ATT_COM R2 "timestamp" "000CFBEB" .ATT_COM R2 "Cost1000" "0.00710" .ATT_COM R2 "Pack" "100" .ATT_COM R2 "Source Package" "R" .ATT_COM R2 "Order Code" "72-0397" .ATT_COM R2 "Value" "1M" .ATT_COM R2 "Cost25" "0.023" .ADD_COM R20 "0805" .ATT_COM R20 "Cost100" "0.006" .ATT_COM R20 "Supplier" "RE" .ATT_COM R20 "PCB Footprint" "0805" .ATT_COM R20 "Cost1" "0.023" .ATT_COM R20 "timestamp" "000CC2F0" .ATT_COM R20 "Cost1000" "0.00710" .ATT_COM R20 "Pack" "100" .ATT_COM R20 "Source Package" "R" .ATT_COM R20 "Order Code" "72-4392" .ATT_COM R20 "Value" "120R" .ATT_COM R20 "Cost25" "0.023" .ADD_COM R21 "0805" .ATT_COM R21 "Cost100" "0.006" .ATT_COM R21 "Supplier" "RE" .ATT_COM R21 "PCB Footprint" "0805" .ATT_COM R21 "Cost1" "0.023" .ATT_COM R21 "timestamp" "000CC1AE" .ATT_COM R21 "Cost1000" "0.00710" .ATT_COM R21 "Pack" "100" .ATT_COM R21 "Source Package" "R" .ATT_COM R21 "Order Code" "72-4392" .ATT_COM R21 "Value" "120R" .ATT_COM R21 "Cost25" "0.023" .ADD_COM R22 "0805" .ATT_COM R22 "Cost100" "0.006" .ATT_COM R22 "Supplier" "RE" .ATT_COM R22 "PCB Footprint" "0805" .ATT_COM R22 "Cost1" "0.023" .ATT_COM R22 "timestamp" "000CC06C" .ATT_COM R22 "Cost1000" "0.00710" .ATT_COM R22 "Pack" "100" .ATT_COM R22 "Source Package" "R" .ATT_COM R22 "Order Code" "72-4392" .ATT_COM R22 "Value" "120R" .ATT_COM R22 "Cost25" "0.023" .ADD_COM R23 "0805" .ATT_COM R23 "Cost100" "0.006" .ATT_COM R23 "Supplier" "RE" .ATT_COM R23 "PCB Footprint" "0805" .ATT_COM R23 "Cost1" "0.023" .ATT_COM R23 "timestamp" "000CC23C" .ATT_COM R23 "Cost1000" "0.00710" .ATT_COM R23 "Pack" "100" .ATT_COM R23 "Source Package" "R" .ATT_COM R23 "Order Code" "72-4392" .ATT_COM R23 "Value" "120R" .ATT_COM R23 "Cost25" "0.023" .ADD_COM R24 "0805" .ATT_COM R24 "Cost100" "0.006" .ATT_COM R24 "Supplier" "RE" .ATT_COM R24 "PCB Footprint" "0805" .ATT_COM R24 "Cost1" "0.023" .ATT_COM R24 "timestamp" "000CC0FA" .ATT_COM R24 "Cost1000" "0.00710" .ATT_COM R24 "Pack" "100" .ATT_COM R24 "Source Package" "R" .ATT_COM R24 "Order Code" "72-4392" .ATT_COM R24 "Value" "120R" .ATT_COM R24 "Cost25" "0.023" .ADD_COM R25 "0805" .ATT_COM R25 "Cost100" "0.006" .ATT_COM R25 "Supplier" "RE" .ATT_COM R25 "PCB Footprint" "0805" .ATT_COM R25 "Cost1" "0.023" .ATT_COM R25 "timestamp" "000CBFB8" .ATT_COM R25 "Cost1000" "0.00710" .ATT_COM R25 "Pack" "100" .ATT_COM R25 "Source Package" "R" .ATT_COM R25 "Order Code" "72-4392" .ATT_COM R25 "Value" "120R" .ATT_COM R25 "Cost25" "0.023" .ADD_COM R26 "0805" .ATT_COM R26 "Cost100" "0.006" .ATT_COM R26 "Supplier" "RE" .ATT_COM R26 "PCB Footprint" "0805" .ATT_COM R26 "Cost1" "0.023" .ATT_COM R26 "timestamp" "000CC2D8" .ATT_COM R26 "Cost1000" "0.00710" .ATT_COM R26 "Pack" "100" .ATT_COM R26 "Source Package" "R" .ATT_COM R26 "Order Code" "72-4392" .ATT_COM R26 "Value" "120R" .ATT_COM R26 "Cost25" "0.023" .ADD_COM R27 "0805" .ATT_COM R27 "Cost100" "0.006" .ATT_COM R27 "Supplier" "RE" .ATT_COM R27 "PCB Footprint" "0805" .ATT_COM R27 "Cost1" "0.023" .ATT_COM R27 "timestamp" "000CC196" .ATT_COM R27 "Cost1000" "0.00710" .ATT_COM R27 "Pack" "100" .ATT_COM R27 "Source Package" "R" .ATT_COM R27 "Order Code" "72-4392" .ATT_COM R27 "Value" "120R" .ATT_COM R27 "Cost25" "0.023" .ADD_COM R28 "0805" .ATT_COM R28 "Cost100" "0.006" .ATT_COM R28 "Supplier" "RE" .ATT_COM R28 "PCB Footprint" "0805" .ATT_COM R28 "Cost1" "0.023" .ATT_COM R28 "timestamp" "000CC054" .ATT_COM R28 "Cost1000" "0.00710" .ATT_COM R28 "Pack" "100" .ATT_COM R28 "Source Package" "R" .ATT_COM R28 "Order Code" "72-4392" .ATT_COM R28 "Value" "120R" .ATT_COM R28 "Cost25" "0.023" .ADD_COM R29 "0805" .ATT_COM R29 "Cost100" "0.006" .ATT_COM R29 "Supplier" "RE" .ATT_COM R29 "PCB Footprint" "0805" .ATT_COM R29 "timestamp" "000DAA80" .ATT_COM R29 "Pack" "100" .ATT_COM R29 "Source Package" "R" .ATT_COM R29 "Value" "8.2K" .ADD_COM R3 "0805" .ATT_COM R3 "Cost100" "0.006" .ATT_COM R3 "Supplier" "RE" .ATT_COM R3 "PCB Footprint" "0805" .ATT_COM R3 "timestamp" "000DADEB" .ATT_COM R3 "Pack" "100" .ATT_COM R3 "Source Package" "R" .ATT_COM R3 "Value" "8.2K" .ADD_COM R30 "0805" .ATT_COM R30 "Cost100" "0.006" .ATT_COM R30 "Supplier" "RE" .ATT_COM R30 "PCB Footprint" "0805" .ATT_COM R30 "timestamp" "000DB08F" .ATT_COM R30 "Pack" "100" .ATT_COM R30 "Source Package" "R" .ATT_COM R30 "Value" "8.2K" .ADD_COM R31 "0805" .ATT_COM R31 "Cost100" "0.006" .ATT_COM R31 "Supplier" "RE" .ATT_COM R31 "PCB Footprint" "0805" .ATT_COM R31 "timestamp" "000DB0BB" .ATT_COM R31 "Pack" "100" .ATT_COM R31 "Source Package" "R" .ATT_COM R31 "Value" "8.2K" .ADD_COM R32 "0805" .ATT_COM R32 "Cost100" "0.006" .ATT_COM R32 "Supplier" "RE" .ATT_COM R32 "PCB Footprint" "0805" .ATT_COM R32 "timestamp" "000DB0D3" .ATT_COM R32 "Pack" "100" .ATT_COM R32 "Source Package" "R" .ATT_COM R32 "Value" "8.2K" .ADD_COM R33 "0805" .ATT_COM R33 "Cost100" "0.006" .ATT_COM R33 "Supplier" "RE" .ATT_COM R33 "PCB Footprint" "0805" .ATT_COM R33 "timestamp" "000DB12B" .ATT_COM R33 "Pack" "100" .ATT_COM R33 "Source Package" "R" .ATT_COM R33 "Value" "8.2K" .ADD_COM R34 "0805" .ATT_COM R34 "Cost100" "0.006" .ATT_COM R34 "Supplier" "RE" .ATT_COM R34 "PCB Footprint" "0805" .ATT_COM R34 "timestamp" "000DB143" .ATT_COM R34 "Pack" "100" .ATT_COM R34 "Source Package" "R" .ATT_COM R34 "Value" "8.2K" .ADD_COM R35 "0805" .ATT_COM R35 "Cost100" "0.006" .ATT_COM R35 "Supplier" "RE" .ATT_COM R35 "PCB Footprint" "0805" .ATT_COM R35 "timestamp" "000DB15B" .ATT_COM R35 "Pack" "100" .ATT_COM R35 "Source Package" "R" .ATT_COM R35 "Value" "8.2K" .ADD_COM R36 "0805" .ATT_COM R36 "Cost100" "0.006" .ATT_COM R36 "Supplier" "RE" .ATT_COM R36 "PCB Footprint" "0805" .ATT_COM R36 "timestamp" "000DB173" .ATT_COM R36 "Pack" "100" .ATT_COM R36 "Source Package" "R" .ATT_COM R36 "Value" "8.2K" .ADD_COM R37 "0805" .ATT_COM R37 "Cost100" "0.006" .ATT_COM R37 "Supplier" "RE" .ATT_COM R37 "PCB Footprint" "0805" .ATT_COM R37 "timestamp" "000DB1DB" .ATT_COM R37 "Pack" "100" .ATT_COM R37 "Source Package" "R" .ATT_COM R37 "Value" "8.2K" .ADD_COM R38 "0805" .ATT_COM R38 "Cost100" "0.006" .ATT_COM R38 "Supplier" "RE" .ATT_COM R38 "PCB Footprint" "0805" .ATT_COM R38 "timestamp" "000DB1F3" .ATT_COM R38 "Pack" "100" .ATT_COM R38 "Source Package" "R" .ATT_COM R38 "Value" "8.2K" .ADD_COM R39 "0805" .ATT_COM R39 "Cost100" "0.006" .ATT_COM R39 "Supplier" "RE" .ATT_COM R39 "PCB Footprint" "0805" .ATT_COM R39 "timestamp" "000DB20B" .ATT_COM R39 "Pack" "100" .ATT_COM R39 "Source Package" "R" .ATT_COM R39 "Value" "8.2K" .ADD_COM R4 "0805" .ATT_COM R4 "Cost100" "0.006" .ATT_COM R4 "Supplier" "RE" .ATT_COM R4 "PCB Footprint" "0805" .ATT_COM R4 "timestamp" "000DACD7" .ATT_COM R4 "Pack" "100" .ATT_COM R4 "Source Package" "R" .ATT_COM R4 "Value" "8.2K" .ADD_COM R40 "0805" .ATT_COM R40 "Cost100" "0.006" .ATT_COM R40 "Supplier" "RE" .ATT_COM R40 "PCB Footprint" "0805" .ATT_COM R40 "timestamp" "000DB223" .ATT_COM R40 "Pack" "100" .ATT_COM R40 "Source Package" "R" .ATT_COM R40 "Value" "8.2K" .ADD_COM R41 "0805" .ATT_COM R41 "Cost100" "0.006" .ATT_COM R41 "Supplier" "RE" .ATT_COM R41 "PCB Footprint" "0805" .ATT_COM R41 "timestamp" "000DB23B" .ATT_COM R41 "Pack" "100" .ATT_COM R41 "Source Package" "R" .ATT_COM R41 "Value" "8.2K" .ADD_COM R42 "0805" .ATT_COM R42 "Cost100" "0.006" .ATT_COM R42 "Supplier" "RE" .ATT_COM R42 "PCB Footprint" "0805" .ATT_COM R42 "timestamp" "000DB253" .ATT_COM R42 "Pack" "100" .ATT_COM R42 "Source Package" "R" .ATT_COM R42 "Value" "8.2K" .ADD_COM R43 "0805" .ATT_COM R43 "Cost100" "0.006" .ATT_COM R43 "Supplier" "RE" .ATT_COM R43 "PCB Footprint" "0805" .ATT_COM R43 "timestamp" "000DB26B" .ATT_COM R43 "Pack" "100" .ATT_COM R43 "Source Package" "R" .ATT_COM R43 "Value" "8.2K" .ADD_COM R44 "0805" .ATT_COM R44 "Cost100" "0.006" .ATT_COM R44 "Supplier" "RE" .ATT_COM R44 "PCB Footprint" "0805" .ATT_COM R44 "timestamp" "000DB283" .ATT_COM R44 "Pack" "100" .ATT_COM R44 "Source Package" "R" .ATT_COM R44 "Value" "8.2K" .ADD_COM R45 "0805" .ATT_COM R45 "Cost100" "0.006" .ATT_COM R45 "Supplier" "RE" .ATT_COM R45 "PCB Footprint" "0805" .ATT_COM R45 "timestamp" "000DB80E" .ATT_COM R45 "Pack" "100" .ATT_COM R45 "Source Package" "R" .ATT_COM R45 "Value" "8.2K" .ADD_COM R46 "0805" .ATT_COM R46 "Cost100" "0.006" .ATT_COM R46 "Supplier" "RE" .ATT_COM R46 "PCB Footprint" "0805" .ATT_COM R46 "timestamp" "000DB826" .ATT_COM R46 "Pack" "100" .ATT_COM R46 "Source Package" "R" .ATT_COM R46 "Value" "8.2K" .ADD_COM R47 "0805" .ATT_COM R47 "Cost100" "0.006" .ATT_COM R47 "Supplier" "RE" .ATT_COM R47 "PCB Footprint" "0805" .ATT_COM R47 "timestamp" "000DB83E" .ATT_COM R47 "Pack" "100" .ATT_COM R47 "Source Package" "R" .ATT_COM R47 "Value" "8.2K" .ADD_COM R48 "0805" .ATT_COM R48 "Cost100" "0.006" .ATT_COM R48 "Supplier" "RE" .ATT_COM R48 "PCB Footprint" "0805" .ATT_COM R48 "timestamp" "000DB856" .ATT_COM R48 "Pack" "100" .ATT_COM R48 "Source Package" "R" .ATT_COM R48 "Value" "8.2K" .ADD_COM R49 "0805" .ATT_COM R49 "Cost100" "0.006" .ATT_COM R49 "Supplier" "RE" .ATT_COM R49 "Cost1" "0.023" .ATT_COM R49 "PCB Footprint" "0805" .ATT_COM R49 "timestamp" "000DE221" .ATT_COM R49 "Pack" "100" .ATT_COM R49 "Cost1000" "0.00710" .ATT_COM R49 "Source Package" "R" .ATT_COM R49 "Order Code" "72-4392" .ATT_COM R49 "Value" "120R" .ATT_COM R49 "Cost25" "0.023" .ADD_COM R5 "0805" .ATT_COM R5 "Cost100" "0.006" .ATT_COM R5 "Supplier" "RE" .ATT_COM R5 "PCB Footprint" "0805" .ATT_COM R5 "Cost1" "0.023" .ATT_COM R5 "timestamp" "000D12E8" .ATT_COM R5 "Cost1000" "0.00710" .ATT_COM R5 "Pack" "100" .ATT_COM R5 "Source Package" "R" .ATT_COM R5 "Order Code" "72-4392" .ATT_COM R5 "Value" "120R" .ATT_COM R5 "Cost25" "0.023" .ADD_COM R50 "0805" .ATT_COM R50 "Cost100" "0.006" .ATT_COM R50 "Supplier" "RE" .ATT_COM R50 "Cost1" "0.023" .ATT_COM R50 "PCB Footprint" "0805" .ATT_COM R50 "timestamp" "000DAABD" .ATT_COM R50 "Cost1000" "0.00710" .ATT_COM R50 "Pack" "100" .ATT_COM R50 "Source Package" "R" .ATT_COM R50 "Order Code" "72-4392" .ATT_COM R50 "Value" "120R" .ATT_COM R50 "Cost25" "0.023" .ADD_COM R6 "0805" .ATT_COM R6 "Cost100" "0.006" .ATT_COM R6 "Supplier" "RE" .ATT_COM R6 "PCB Footprint" "0805" .ATT_COM R6 "Cost1" "0.023" .ATT_COM R6 "timestamp" "000D29A6" .ATT_COM R6 "Cost1000" "0.00710" .ATT_COM R6 "Pack" "100" .ATT_COM R6 "Source Package" "R" .ATT_COM R6 "Order Code" "72-4392" .ATT_COM R6 "Value" "120R" .ATT_COM R6 "Cost25" "0.023" .ADD_COM R7 "0805" .ATT_COM R7 "Cost100" "0.006" .ATT_COM R7 "Supplier" "RE" .ATT_COM R7 "PCB Footprint" "0805" .ATT_COM R7 "Cost1" "0.023" .ATT_COM R7 "timestamp" "000D29D3" .ATT_COM R7 "Cost1000" "0.00710" .ATT_COM R7 "Pack" "100" .ATT_COM R7 "Source Package" "R" .ATT_COM R7 "Order Code" "72-4392" .ATT_COM R7 "Value" "120R" .ATT_COM R7 "Cost25" "0.023" .ADD_COM R8 "0805" .ATT_COM R8 "Cost100" "0.006" .ATT_COM R8 "Supplier" "RE" .ATT_COM R8 "PCB Footprint" "0805" .ATT_COM R8 "Cost1" "0.023" .ATT_COM R8 "timestamp" "000D29EE" .ATT_COM R8 "Cost1000" "0.00710" .ATT_COM R8 "Pack" "100" .ATT_COM R8 "Source Package" "R" .ATT_COM R8 "Order Code" "72-4392" .ATT_COM R8 "Value" "120R" .ATT_COM R8 "Cost25" "0.023" .ADD_COM R9 "0805" .ATT_COM R9 "Cost100" "0.006" .ATT_COM R9 "Supplier" "RE" .ATT_COM R9 "PCB Footprint" "0805" .ATT_COM R9 "Cost1" "0.023" .ATT_COM R9 "timestamp" "000CC31C" .ATT_COM R9 "Cost1000" "0.00710" .ATT_COM R9 "Pack" "100" .ATT_COM R9 "Source Package" "R" .ATT_COM R9 "Order Code" "72-4392" .ATT_COM R9 "Value" "120R" .ATT_COM R9 "Cost25" "0.023" .ADD_COM SW1 "see data" .ATT_COM SW1 "Cost100" "0.135" .ATT_COM SW1 "Supplier" "RE" .ATT_COM SW1 "Cost1" "0.18" .ATT_COM SW1 "PCB Footprint" "see data" .ATT_COM SW1 "timestamp" "000D3EFB" .ATT_COM SW1 "Source Package" "SW_T_SPDT" .ATT_COM SW1 "Order Code" "76-0265" .ATT_COM SW1 "Value" "SW_T_SPDT" .ATT_COM SW1 "Man Ref" "SS-5806-012 series vertical" .ADD_COM SW2 "SMT" .ATT_COM SW2 "Cost100" "0.22" .ATT_COM SW2 "Supplier" "RE" .ATT_COM SW2 "PCB Footprint" "SMT" .ATT_COM SW2 "Cost1" "0.28" .ATT_COM SW2 "timestamp" "000C8C6F" .ATT_COM SW2 "Source Package" "SW_TC_SPST" .ATT_COM SW2 "Manu" "Diptronics" .ATT_COM SW2 "Order Code" "72-4190" .ATT_COM SW2 "Man ref" "DTSMW-66N" .ATT_COM SW2 "Value" "Button" .ADD_COM SW3 "SMT" .ATT_COM SW3 "Cost100" "0.22" .ATT_COM SW3 "Supplier" "RE" .ATT_COM SW3 "PCB Footprint" "SMT" .ATT_COM SW3 "Cost1" "0.28" .ATT_COM SW3 "timestamp" "000C7E1B" .ATT_COM SW3 "Source Package" "SW_TC_SPST" .ATT_COM SW3 "Manu" "Diptronics" .ATT_COM SW3 "Order Code" "72-4190" .ATT_COM SW3 "Man ref" "DTSMW-66N" .ATT_COM SW3 "Value" "Button" .ADD_TER IC3 42 "ALT0" .TER JP1 2 .ADD_TER IC3 38 "ALT2" .TER JP1 6 .ADD_TER IC3 35 "ALT3" .TER JP1 8 .ADD_TER IC2 G6 "XIL1" .TER JP1 3 .ADD_TER IC2 E5 "XIL3" .TER JP1 7 .ADD_TER IC2 E7 "XIL2" .TER JP1 5 .ADD_TER IC2 F5 "XIL0" .TER JP1 1 .ADD_TER JP2 1 "N864718" .TER IC5 9 .ADD_TER JP2 3 "N864801" .TER IC5 10 .ADD_TER JP2 5 "N864884" .TER IC5 11 .ADD_TER JP2 7 "N864967" .TER IC5 13 .ADD_TER IC2 D7 "NET0" .TER IC3 34 .ADD_TER IC2 D6 "NET1" .TER IC3 33 .ADD_TER IC3 39 "NALT1" .TER IC1 2 .ADD_TER R1 2 "N851510" .TER IC1 3 C1 1 .ADD_TER IC1 4 "N851502" .TER R1 1 IC1 5 .ADD_TER IC1 6 "CLOCKS" .TER IC3 37 IC2 B7 .ADD_TER IC1 10 "CLOCKF" .TER IC3 40 IC2 B6 .ADD_TER IC1 9 "N851026" .TER R2 2 C2 1 .ADD_TER IC1 8 "N850953" .TER R2 1 IC1 11 .ADD_TER IC5 21 "NWE" .TER IC3 28 R48 1 .ADD_TER IC5 20 "NOE" .TER IC3 31 R47 1 .ADD_TER IC1 7 "GND" .TER CN1 4 IC2 F3 JP7 3 JP7 2 IC3 4 C6 2 C7 2 C2 2 IC1 13 CN2 2 CN1 3 CN1 11 IC5 12 CN1 12 C1 2 IC2 A5 JP4 8 JP4 7 JP4 5 JP4 4 JP4 3 JP4 2 CN1 10 IC5 18 SW2 2 JP7 5 JP7 4 CN1 6 CN1 8 IC3 16 C11 2 IC3 30 JP7 8 JP7 7 IC4 4 R39 1 R38 1 R42 1 R41 1 R37 1 R36 1 R32 1 R31 1 R29 1 R45 1 R44 1 CN1 19 R46 1 C5 2 JP4 1 JP7 9 C9 2 JP7 10 IC3 24 R33 1 IC4 7 IC3 11 CN1 14 CN1 16 R34 1 IC4 3 CN1 20 D1 1 R43 1 C3 2 D9 1 D3 1 C8 2 R40 1 JP4 6 D4 1 JP7 6 C10 2 IC4 1 R50 2 CN1 18 R35 1 C4 2 JP4 10 IC3 36 D6 1 D8 1 JP4 9 D7 1 SW3 2 SW1 3 D2 1 R30 1 IC2 D1 IC4 2 D5 1 JP7 1 .ADD_TER IC1 14 "3.3V" .TER R13 2 CN1 1 IC2 C1 IC2 G3 IC2 F7 R12 2 R3 2 R4 2 IC4 8 JP5 1 JP5 5 JP5 3 JP5 7 JP5 9 JP5 11 JP5 13 JP5 15 JP5 19 JP5 17 JP6 20 JP6 18 JP6 14 JP6 12 JP6 2 JP6 4 JP6 6 JP6 8 JP6 10 JP6 16 IC3 29 IC3 9 IC3 17 IC3 41 C5 1 C4 1 C11 1 C10 1 C7 1 C6 1 C9 1 C8 1 C3 1 IC5 24 SW1 1 CN2 1 R48 2 R47 2 .ADD_TER R3 1 "SDA" .TER IC4 5 IC3 43 IC2 G7 .ADD_TER R4 1 "SCL" .TER IC4 6 IC3 44 IC2 A7 .ADD_TER JP6 11 "DIL14" .TER CN3 15 IC5 2 IC3 22 R43 2 .ADD_TER CN3 4 "DIL3" .TER JP5 8 JP2 8 IC3 6 R32 2 .ADD_TER CN3 1 "DIL0" .TER JP5 2 JP2 2 IC3 2 R29 2 .ADD_TER CN3 10 "DIL9" .TER JP5 20 IC5 7 IC3 15 R38 2 .ADD_TER JP6 15 "DIL12" .TER CN3 13 IC5 4 IC3 20 R41 2 .ADD_TER CN3 5 "DIL4" .TER JP5 10 IC5 14 IC3 8 R33 2 .ADD_TER JP6 19 "DIL10" .TER CN3 11 IC5 6 IC3 18 R39 2 .ADD_TER JP6 17 "DIL11" .TER CN3 12 IC5 5 IC3 19 R40 2 .ADD_TER JP6 3 "DIL18" .TER CN3 19 IC2 F6 R7 2 .ADD_TER CN3 2 "DIL1" .TER JP5 4 JP2 4 IC3 3 R30 2 .ADD_TER JP6 1 "DIL19" .TER CN3 20 IC2 E6 R8 2 .ADD_TER JP6 13 "DIL13" .TER CN3 14 IC5 3 IC3 21 R42 2 .ADD_TER CN3 6 "DIL5" .TER JP5 12 IC5 15 IC3 10 R34 2 .ADD_TER JP6 5 "DIL17" .TER CN3 18 IC3 27 R6 2 R46 2 .ADD_TER CN3 3 "DIL2" .TER JP5 6 JP2 6 IC3 5 R31 2 .ADD_TER CN3 8 "DIL7" .TER JP5 16 IC5 17 IC3 13 R36 2 .ADD_TER IC3 32 "N895353" .TER R49 1 .ADD_TER JP6 7 "DIL16" .TER CN3 17 IC3 25 R5 2 R45 2 .ADD_TER CN3 9 "DIL8" .TER JP5 18 IC5 8 IC3 14 R37 2 .ADD_TER D5 2 "N835810" .TER R21 1 .ADD_TER R10 2 "LED6" .TER IC2 B2 .ADD_TER CN3 7 "DIL6" .TER JP5 14 IC5 16 IC3 12 R35 2 .ADD_TER R27 2 "LED11" .TER IC2 E1 .ADD_TER JP6 9 "DIL15" .TER CN3 16 IC3 23 R44 2 .ADD_TER R22 2 "LED15" .TER IC2 F2 .ADD_TER R9 2 "LED0" .TER IC2 A6 .ADD_TER D5 3 "N836102" .TER R18 1 .ADD_TER CN1 5 "TDI" .TER IC2 B3 .ADD_TER D8 2 "N835914" .TER R27 1 .ADD_TER R21 2 "LED9" .TER IC2 C3 .ADD_TER IC2 G2 "TDO/TDI" .TER IC3 1 .ADD_TER CN1 7 "TMS" .TER IC2 A2 IC3 7 .ADD_TER D3 3 "N835564" .TER R11 1 .ADD_TER CN1 13 "TDO" .TER R49 2 .ADD_TER D1 3 "N836208" .TER R9 1 .ADD_TER CN1 9 "TCLK" .TER IC3 26 IC2 A1 R50 1 .ADD_TER D7 2 "N836236" .TER R26 1 .ADD_TER R16 2 "LED13" .TER IC2 F1 .ADD_TER R18 2 "LED8" .TER IC2 C2 .ADD_TER D9 2 "N835592" .TER R28 1 .ADD_TER R14 2 "LED1" .TER IC2 C5 .ADD_TER D2 2 "N835970" .TER R15 1 .ADD_TER D3 2 "N835648" .TER R16 1 .ADD_TER D6 2 "N835488" .TER R22 1 .ADD_TER R19 2 "LED14" .TER IC2 G1 .ADD_TER R23 2 "LED4" .TER IC2 B4 .ADD_TER R26 2 "LED5" .TER IC2 A3 .ADD_TER R15 2 "LED7" .TER IC2 B1 .ADD_TER R25 2 "LED16" .TER IC2 E3 .ADD_TER R28 2 "LED17" .TER IC2 G4 .ADD_TER D1 2 "N836292" .TER R14 1 .ADD_TER R17 2 "LED2" .TER IC2 B5 .ADD_TER D6 3 "N835780" .TER R19 1 .ADD_TER D4 3 "N836424" .TER R17 1 .ADD_TER D7 3 "N836388" .TER R23 1 .ADD_TER R20 2 "LED3" .TER IC2 A4 .ADD_TER R24 2 "LED10" .TER IC2 D2 .ADD_TER D8 3 "N836066" .TER R24 1 .ADD_TER D2 3 "N835886" .TER R10 1 .ADD_TER D9 3 "N835744" .TER R25 1 .ADD_TER D4 2 "N836132" .TER R20 1 .ADD_TER R11 2 "LED12" .TER IC2 E2 .ADD_TER R13 1 "BUT1" .TER SW3 3 IC2 G5 .ADD_TER R12 1 "BUT0" .TER SW2 3 IC2 F4 .ADD_TER JP3 3 "N848809" .TER R6 1 .ADD_TER JP3 1 "N848870" .TER R5 1 .ADD_TER JP3 5 "N848931" .TER R7 1 .ADD_TER JP3 7 "N848992" .TER R8 1 .ADD_TER CN1 15 "GP0" .TER IC2 C7 .ADD_TER IC2 C6 "GP1" .TER SW1 2 CN1 17 .ADD_TER IC5 1 "N863487" .TER JP3 2 .ADD_TER IC5 23 "N863570" .TER JP3 4 .ADD_TER IC5 22 "N863653" .TER JP3 6 .ADD_TER IC5 19 "N863736" .TER JP3 8 .ADD_TER JP1 4 "ALT1" .TER IC1 1 .END 416966fa52d58d24b23b39c8dadb7e3e2a36da28 0 21 573 391 2009-06-08T07:27:48Z Hsa061 18 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] df104925bfd350b08e16b3459f0b7104b142a898 577 573 2009-06-09T08:58:11Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] 1b29e6678c0b864ff54d95615a9a053e550e205f 626 577 2009-08-19T10:43:51Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] == Upcoming meetings and conferences== * TWEPP 09, Paris, 21.-25.09.09: http://twepp09.lal.in2p3.fr/ * CALICE Collaboration Autumn Meeting, Lyon, 16.-18.09.09 * RD09, Florence, 30.09.-02.10.09: http://www.fi.infn.it/conferenze/rd09/ 62ed802323b0faf3f303b9ba1a3d7ce0d2e9ece6 627 626 2009-08-19T10:47:49Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == Lab equipment list, how to's, equipment service log's etc... * [[Lab Equipment]] == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] == Upcoming meetings and conferences== * CALICE Collaboration Autumn Meeting, Lyon, 16.-18.09.09 * TWEPP 09, Paris, 21.-25.09.09: http://twepp09.lal.in2p3.fr/ * RD09, Florence, 30.09.-02.10.09: http://www.fi.infn.it/conferenze/rd09/ 1e232af7ec4b78178ebfdb88d5ebfb2a82448b0c 628 627 2009-08-19T11:37:20Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == * [[Lab equipment list]] - instruments we have available, manuals, how to's * [[Wishlist]] - put the things here that you need for your projects == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] == Upcoming meetings and conferences== * CALICE Collaboration Autumn Meeting, Lyon, 16.-18.09.09 * TWEPP 09, Paris, 21.-25.09.09: http://twepp09.lal.in2p3.fr/ * RD09, Florence, 30.09.-02.10.09: http://www.fi.infn.it/conferenze/rd09/ 83c7ab10013414efd16a4cb90ac226b9dce321cf 629 628 2009-08-19T11:38:55Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] Lab equipment list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] == Upcoming meetings and conferences== * CALICE Collaboration Autumn Meeting, Lyon, 16.-18.09.09 * TWEPP 09, Paris, 21.-25.09.09: http://twepp09.lal.in2p3.fr/ * RD09, Florence, 30.09.-02.10.09: http://www.fi.infn.it/conferenze/rd09/ ee2bdad860cc3c812b38de8b21c20fb4b7bce5b9 631 629 2009-08-19T11:42:17Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] == Upcoming meetings and conferences== * CALICE Collaboration Autumn Meeting, Lyon, 16.-18.09.09 * TWEPP 09, Paris, 21.-25.09.09: http://twepp09.lal.in2p3.fr/ * RD09, Florence, 30.09.-02.10.09: http://www.fi.infn.it/conferenze/rd09/ 77e34392227319d00d1b4da7e7bbd97f13ed1b52 632 631 2009-08-19T11:42:39Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] == Upcoming meetings and conferences== * CALICE Collaboration Autumn Meeting, Lyon, 16.-18.09.09 * TWEPP 09, Paris, 21.-25.09.09: http://twepp09.lal.in2p3.fr/ * RD09, Florence, 30.09.-02.10.09: http://www.fi.infn.it/conferenze/rd09/ 78fd1cfff03ce74c7871b26e49ad508864bec679 633 632 2009-08-19T11:43:36Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Where are we? == * The main laboratory is situated in the 3rd floor at the IFT, room 332. == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The clean room * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] [[older presentations]] == Upcoming meetings and conferences== * CALICE Collaboration Autumn Meeting, Lyon, 16.-18.09.09 * TWEPP 09, Paris, 21.-25.09.09: http://twepp09.lal.in2p3.fr/ * RD09, Florence, 30.09.-02.10.09: http://www.fi.infn.it/conferenze/rd09/ 1cf431f1976d55a537fc56ace8f74771f58c1efb 634 633 2009-08-21T07:17:42Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] [[older presentations]] == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ 89fe8749b86e00ece9e66333f8c327dd6de0e735 635 634 2009-08-21T07:22:10Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] [[older presentations]] == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. 8b3f67473d94cb23161b795ff50a2e7301aa2f1e 0 191 574 2009-06-08T07:34:33Z Hsa061 18 Created page with '== Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays primarily in collaboration with high school students and tea...' wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays primarily in collaboration with high school students and teachers, but master students will also be involved in the upgrade and extension of this system. == General description == To be provided... == More information == * Øyvind's thesis which gives a good description of our setup. A link to this thesis will be provided. * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 381fb6fcdb9c4a95e214a30de90a954a6a863021 0 22 578 407 2009-06-12T09:06:50Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === [[Image:MAPD_radiotracer.JPG‎|frame|right|200px|Fluorodeoxyglucose-FDG]] [[Image:MAPD_positronelectronannihilation.JPG‎‎|frame|left|200px|Positron - Electron Annihilation]] The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === [[Image:MAPD_crystaltransition.JPG‎ |frame|left|200px|Electronic transition in a crystal]] A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === [[Image:MAPD_coincidenceprinciple.JPG‎ |frame|none|200px|Coincidence detection principle]] In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. [[Image:MAPD_coincidencecategories.JPG|frame||200px|3 different coincidence detection events]] * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. [[Image:MAPD tofprinciple.jpg‎ |frame|none|200px|Time of flight principle]] [[Image:MAPD tofprinciple2.JPG|frame|none|200px|Time of flight principle]] == Technology == === Avalanche Photodiodes === [[Image:MAPD structure.jpg‎|frame|right|200px|Structure of MAPD]] An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. [[Image:MAPD proportionalmode.jpg‎ ‎|frame|right|200px|proportional mode]] * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. [[Image:MAPD geigermode.jpg‎‎|frame|right|200px|Geiger mode]] [[Image:MAPD_passivequenching.jpg‎‎|frame|right|200px|passive quenching]] The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. [[User:Dfe002|Dominik]] 09:06, 12 June 2009 (UTC) [[Category:Detector lab]] 7104ae250dcd9dcf06023af2b7c5dcc59346a1af 579 578 2009-06-12T09:08:28Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === [[Image:MAPD_radiotracer.JPG‎|frame|right|200px|Fluorodeoxyglucose-FDG]] [[Image:MAPD_positronelectronannihilation.JPG‎‎|frame|left|200px|Positron - Electron Annihilation]] The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === [[Image:MAPD_crystaltransition.JPG‎ |frame|left|200px|Electronic transition in a crystal]] A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === [[Image:MAPD_coincidenceprinciple.JPG‎ |frame|none|200px|Coincidence detection principle]] In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. [[Image:MAPD_coincidencecategories.JPG|frame||200px|3 different coincidence detection events]] * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. [[Image:MAPD tofprinciple.jpg‎ |frame|none|200px|Time of flight principle]] [[Image:MAPD tofprinciple2.JPG|frame|none|200px|Time of flight principle]] == Technology == === Avalanche Photodiodes === [[Image:MAPD structure.jpg‎|frame|right|200px|Structure of MAPD]] An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. [[Image:MAPD proportionalmode.jpg‎ ‎|frame|right|200px|proportional mode]] * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. [[Image:MAPD geigermode.jpg‎‎|frame|right|200px|Geiger mode]] [[Image:MAPD_passivequenching.jpg‎‎|frame|right|200px|passive quenching]] The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. === Documentation === [[User:Dfe002|Dominik]] 09:06, 12 June 2009 (UTC) [[Category:Detector lab]] 7e3b37af69797e2b8dbe9d9a37be39d95708bf4f 580 579 2009-06-12T09:12:53Z Dfe002 7 wikitext text/x-wiki == Goal == The MEDUSA project focuses on R&D for high energy physics instrumentation with two important and dependant goals. One is to contribute to the research for future particle detectors and develop new improved detectors for the LHC upgrade as well as the planned international linear collider. The other is to provide new technologies for medical imaging devices such as PET. With this, we hope to contribute to bridging the gap between the particle physics research and the medical technology to fully take advantage of the latest development. [[Image:PETEscan.jpg|frameless|none|500px]] Two complementary detector technologies are highly interesting for medical applications. First, the compact calorimeter is a new technology for detection of photons and hadrons, based on a new type of silicon photomultipliers. These detectors form the base of modern medical imaging technology where precise localisation of radioactive tracers in the body. Aquisition speed and sensitivity are two central challenges for high energy physics. In addition, these detectors can be used to develop Time-of-Flight measurements. The 3D semiconductor devices are based on another new technology, aiming to provide particle and radiation detection by the use of 3 dimensional silicon pixels. The advantage of this method is that these sensors have improved radiation hardness as well as a better to-the-edge detection. A substancial challenge is to provide thin devices and 3D integration, one of the requirement for linear accelerators. Semiconductor detectors are widely used in imaging spectroscopy and particle tracking of ionising radiation, both for charged particles and photons. This project is set up with the collaboration of the new PET center at Haukeland University Hospital and we will closely collaborate with their researchers. Other research partners are the University of Oslo as well as the CLIC, ALICE and the ATLAS collaboration at CERN and the ILC project. == General PET technology == Positron Emission Tomography (PET) is recognized as a great medical imaging devices thanks to its non invasive technology. PET is a type of nuclear medicine procedure that measures metabolic activity of the cells of body tissues. PET is actually a combination of nuclear medicine and biochemical analysis. Used mostly in patients with brain or heart conditions and cancer, its big advantage is to identify the onset of a disease process before anatomical changes (that can be seen with other imaging processes such as computed tomography (CT) or MRI) related to the disease. === Radiotracers === [[Image:MAPD_radiotracer.JPG‎|frame|right|200px|Fluorodeoxyglucose-FDG]] [[Image:MAPD_positronelectronannihilation.JPG‎‎|frame|left|200px|Positron - Electron Annihilation]] The PET technology is based on radioactive emission. Radioactive substances are combined to molecules that the studied cells use particularly in their metabolism. These tracers are radioactive substances. The first step in PET imaging is the production of radionuclides by a cyclotron. These radionuclides will be attached to molecules used by the body before being injected to the patient by intravenous way. The molecule and the adionuclide form the radiotracer. The tracer is injected to the patient and, following the half life of the radionuclide, it will become stable by emitting a positron and a neutrino (the proton which stays in excess will become a neutron). Then, the emitted positron travels a short distance before encountering an electron. When they meet each other, the two particles combine and annihilate each other resulting in the emission of two 511 keV gamma rays in opposite directions. === Scintillators === [[Image:MAPD_crystaltransition.JPG‎ |frame|left|200px|Electronic transition in a crystal]] A scintillator is a substance that absorbs high energy and then, in response, emits photons. Scintillators are defined by their light output (number of emitted photons per unit absorbed energy), short fluorescence decay times, and optical transparency at wavelengths of their own specific emission energy. The high Z-value of the constituents and high density of inorganic crystals favour their choice for gamma-rays spectroscopy (rather than organic crystal) because heavy nucleuses accept better gammas than light nucleus. The scintillation mechanism in inorganic materials depends on energy states determined by the crystal lattice of the material. Absorption of energy can result in the elevation of an electron from its normal position in the valence band across the gap in the conduction ban, leaving a hole in the valence band. A charged particle passing through the detection medium will form a large number of electron-hole pairs, created by the elevation of electrons from the valence to the conduction band. The positive hole will quickly drift to the location of an impurity and ionize it, because the ionization energy of this impurity will be less than that of a typical lattice site. Meanwhile, the electron is free to migrate through the crystal and will do so until it encounters an ionized activator. At this point, the electron can drop into the impurity site, creating a neutral impurity configuration which can have its own set of excited energy states. If the activator state that is formed is an excited configuration with an allowed transition to the ground state, its deexcitation will occur very quickly and with high probability for the emission of the corresponding photon. The migration time for the electronics is shorter than the drop-out time: therefore, the decay time of these states determines the time characteristics of the emitted scintillation light. In order to fully utilize the scintillation light, the spectrum should fall near the wavelength region of maximum sensitivity for the device used to detect the light. {| border="1" cellpadding="2" cellspacing="0" ! !NaI(Ti) !BGO !LSO !LYSO |- |'''ZE''' |50 |74,2 |65 |65 |- |'''Density''' |3,67 |7,13 |7,35 |7,1 |- |'''Attenuation coeff (cm-1)''' |0,34 |0,95 |0,8 |0,83 |- |'''Decay time (ns)''' |230 |300 |40 |42 |} We see, through this chart, that the discovery of the LSO and LYSO crystals have helped to make some progresses. LSO and LYSO crystal are the best compromise for a high attenuation coefficient and a short decay time, two useful properties to improve time resolution in PET scanner. === Coincidence detection === [[Image:MAPD_coincidenceprinciple.JPG‎ |frame|none|200px|Coincidence detection principle]] In a PET camera, each detector generates a time pulse when it registers an incident photon. These pulses are then combined in coincidence circuitry, and if the pulses fall within a short time-window, they are deemed to be coincident. A diagram of this process is shown below: A coincidence event is assigned to a line of response (LOR) joining the two relevant detectors. Coincidence events in PET fall into 3 categories: true, scattered and random. [[Image:MAPD_coincidencecategories.JPG|frame||200px|3 different coincidence detection events]] * '''True coincidences''' occur when both photons from an annihilation event are detected by detectors in coincidence, neither photon undergoes any form of interaction prior to detection, and no other event is detected within the coincidence time-window. * A '''scattered coincidence''' is one in which one of the detected photons (sometimes both) has undergone at least one Compton scattering event prior to detection. Since the direction of the photon is changed during the Compton scattering process, it is highly likely that the resulting coincidence event will be assigned to the wrong LOR. Scattered coincidences add a background to the true coincidence distribution which changes slowly with position, decreasing contrast and causing the isotope concentrations to be overestimated. They also add statistical noise to the signal. The number of scattered events detected depends on the volume and attenuation characteristics of the object being imaged. * '''Random coincidences''' occur when two photons, not arising from the same annihilation event, are incident on the detectors within the coincidence time window of the system. As with scattered events, the number of random coincidences detected also depends on the volume and attenuation characteristics of the object being imaged, and on the geometry of the camera. The distribution of random coincidences is fairly uniform across the field of view and will cause isotope concentrations to be overestimated if not corrected for. Random coincidences also add statistical noise to the data. === Time of Flight === Time-of-flight PET takes advantage of the difference in arrival times of two photons from the same annihilation event to infer spatial information of this event. A detected coincidence between two crystals will have a time difference for any annihilation event that does not occur at the midpoint between the detectors, this time difference is used to place the position of the event. [[Image:MAPD tofprinciple.jpg‎ |frame|none|200px|Time of flight principle]] [[Image:MAPD tofprinciple2.JPG|frame|none|200px|Time of flight principle]] == Technology == === Avalanche Photodiodes === [[Image:MAPD structure.jpg‎|frame|right|200px|Structure of MAPD]] An APD is basically a p-n junction diode operated at large reverse bias voltage. The physical mechanism which avalanche gain depends, is the impact ionization. It occurs when the electric field in the depletion region is strong enough: an electron colliding with a bound valence electron transfers enough energy to this electron to ionize it. The additional carriers can gain sufficient energy from the electric field to cause further impact ionization, creating an avalanche of carriers. * '''proportional mode''' In a proportional counter, each original electron leads to an avalanche which is basically independent of all other avalanches formed from the other electrons associated with the original ionizing event. The collected charge remains proportional to the number of original electrons. [[Image:MAPD proportionalmode.jpg‎ ‎|frame|right|200px|proportional mode]] * '''Geiger mode''' With a higher electric field, a situation is created, in which one avalanche trigger itself a second avalanche at a different position. [[Image:MAPD geigermode.jpg‎‎|frame|right|200px|Geiger mode]] [[Image:MAPD_passivequenching.jpg‎‎|frame|right|200px|passive quenching]] The difference between both modes relies on the holes: in Geiger mode, they trigger avalanches, whereas in proportional mode they have not enough energy to do so. From the critical value of the electric field (corresponding to the breakdown voltage), a self propagating chain reaction occurs. In principle, an exponentially growing number of avalanches could be created. * '''b- Passive quenching''' The avalanche photodiode (i. e. pixel for the silicon photomultiplier) is connected to the power supply through a large series resistor Rs. If the current through the diode tends to zero, the voltage across the diode equals Vbias, which will be larger than the breakdown voltage. So, when the diode breaks down, the series resistor reduces the voltage across the APD, what quenches the avalanche. After the breakdown is quenched, the diode is recharged through the resistor. The APD is now ready to receive another photon. === different MAPDs === The MAPDs are 3 mm *3 mm, composed of 104 pixels /mm2 (9.104 pixels in total). They should be operated in inverse direction: anode should be grounded, while positive voltage in range 132-136V (it depends on the MAPDs and it is reported by the manufacturer). Exceeding the voltage 137V leads to unstable operation and even to the destruction of MAPD. The resistance of each pixel allows the passive quenching. Pixels are electrically decoupled from each other by polysilicon resistors and are connected by common Al strips, in order to readout the MAPD signal. Each MAPD pixel operates as a binary device but MAPD in whole is an analogue detector. The output signal allows us to determine the number of fired pixels: in fact, the output signal is proportional to the number of fired pixels. The MAPD is intrinsically very fast due to the very small width of the depletion region and the extremely short Geiger type discharge. We must keep in mind that the name of the device depends on the manufacturer. MPPC (for Multi-Pixel Photon Counter) and SiPM (Silicon PhotoMultiplier) are two other usual names. === Properties of the devices === * '''Time resolution''': even if photons simultaneously enter different pixels at the same time, the output pulse from each pixel will not necessarily be the same time so that a fluctuation or time jitter occurs. When two photons enter APD pixels at a certain time difference which is shorter than this jitter, then that time difference is impossible to detect. Time resolution is the minimum time difference that can be detected by APD pixels and is defined as FWHM of the distribution of the time jitter. * '''Photon Detection Efficiency (PDE)''': this is a measure of what percent of the incident photons were detected. * '''Dark count''': output pulses are produced not only by photon-generated carriers but also by thermally-generated dark current carriers. The dark current pulses are measured as dark count which then causes detection errors. Although increasing the reverse voltage improves photon detection efficiency, it also increases the dark count. The dark count can be reduced by lowering the temperature. * '''Absolute gain''': the absolute gain is the number of charges which have been created at the output of the MAPD when one photon has hit this device. * '''Quantum efficiency (QE)''': quantum efficiency is a value showing the number of electrons or holes created as photocurrent divided by the number of incident photons, and is usually expressed as a percent. * '''Afterpulse''': afterpulses are spurious pulses following the true signal, which occur when the generated carriers are trapped by crystals defects and then release at a certain delay time. A fterpulses cause detection errors. The lower the temperature, the higher the probability that carriers may be trapped by crystal defects, so afterpulses will increase. * '''Crosstalk''': in an avalanche multiplication process, photons might be generated which are different from photons initially incident on an APD pixel. If those generated photons are detected by other APD pixels, then the MAPD output shows a value higher than the number of photons that were actually input and detected by the MAPD. This phenomenon is thought to be one of the causes of crosstalk in the MAPD. == Documentation == [[User:Dfe002|Dominik]] 09:06, 12 June 2009 (UTC) [[Category:Detector lab]] a096d9da6cf9d7c392082394b791187e8c1c5c9a 6 192 581 2009-06-12T09:15:03Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 193 582 2009-06-12T09:21:32Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 5 612 13 2009-07-07T11:07:09Z Dfe002 7 wikitext text/x-wiki == Purpose == This page acts as a knowledge base for parts of the ALICE Detector Control System (DCS), namely the control of the Front-end electronics of several sub-detectors of ALICE. Since we are mainly involved in the TPC Front-end Electronics, this site may be a bit biased. But it may evolve to a more comprehensive data base for other detectors as well. __TOC__ == Overview == The Detector Control System (DCS) is one of the major modules of the ALICE detector. In general, it covers the tasks of controlling the cooling system, the ventilation system, the magnetic fields and other supports as well as the configuration and monitoring of the Front-end electronics. This page will only cover topics related to the latter. More information on the DCS in general can be found at the [http://alicedcs.web.cern.ch/AliceDCS DCS website]. So far, the following sub-detectors use a number of common components which have been developed in a joint effort: * [http://aliceinfo.cern.ch/Collaboration/ALICE_Project/TPC/index.html Time Projection Chamber (TPC)] * [http://www-alice.gsi.de/trd/index.html Transition Radiation Detector (TRD)] * Photon Spectrometer (PHOS) * Forward Multiplicity Detector (FMD) * EMCAL (new) They all use the DCS board as controlling node on the hardware level. Thus, the communication software can be (almost) identically. The DCS board is a custom-made board with an Altera FPGA that includes an ARM core, which provides the opportunity to run a light-weight Linux system on the card. The board interfaces to the front-end electronics via a dedicated hardware interface and connects to the higher DCS-layers via the DIM communication framework over Ethernet. Furthermore, all detectors but the TRD use a similar hardware setup in the front-end electronics: the Front-End Cards are based on the ALTRO chip and served by Readout Control Units (RCUs). Below is a figure exemplarily for the TPC. [[Image:TPC-FEE blockdia.png|frame|none|Blockdiagram of the TPC Front-end electronics]] === Software Architecture === The DCS consist of three main functional layers. From top to bottom this is: * The Supervisory Layer. The Supervisory Layer provides a user interfaces to the operator. It also communicates with external systems for the LHC * The Control Layer. The Supervisory Layer communicates with the Control Layer mainly through a LAN network. This layer consists of PCs, PLCs (Programmable Logic Cells) and PLC like devices. The Control Layer collects and processes information from the Field Level, as well as sending commands and information from the Supervisory Layer to the Field Layer. It also connects to the Configuration Database. * The Field Layer. The Field Layer consists of all field-devices, sensors, actuators and so on. The DCS board and the readout electronics is located in this layer. For the ALICE experiment, PVSS II has been chosen as SCADA (Supervisory Control And Data Acquisition) system (i.e. the Supervisory Layer). The PVSS connects to the InterComLayer, a specific communication software acting as the Control Layer and connecting the hardware devices in the Field Layer to the controlling system in the Supervisory Layer. The system uses the communication framework [http://www.cern.ch/dim DIM (Distributed Information Management)]. To interfaces are defined for the DCS which abstract the underlaying hardware: * PVSS and InterComLayer communicate through a specific interface, the Front-End-Device (FED), which is common among different sub-detectors within the ALICE experiment. The InterComLayer implements a server which the PVSS can subscribe to as a client. * Each hardware device implements a Front-End-Electronics-Server (FeeServer), which the InterComLayer subscribes to as a client. The InterComLayer connects to several FeeServers and pools data before distributing it to the SCADA system. Vice versa the InterComLayer distributes configuration data to the FeeServers. In addition it implements an interface to the Configuration Database containing all specific configuration data for the hardware devices. [[Image:FeeComChain.PNG|frame|none|Schematic overview of the DCS communication software]] === Hardware Components === * DCS board * Readout-Control-Unit * Frontend Cards * TRD Readout board == The communication software == [[Image:FEE-chain.png|frame|none|DCS data flow for the TPC Front-End-Electronics.]] === Communication Protocol === Communication between all layers is based on the DIM protocol. DIM is an open source communication framework developed at CERN. It provides a network-transparent inter-process communication for distributed and heterogeneous environments. TCP/IP over Ethernet is used as transport layer. A common library for many different operating systems is provided by the framework. DIM implements a client-server relation with two major functionalities. * Services: The DIM server publishes so called services and provides data through a service. Any DIM client can subscribe to services and monitor their data. The DIM clients get notified about current values via a callback from the DIM server. * Commands: A DIM server can accept commands from DIM clients. Server and client have to agree on the format of the command. Here applies the same for the possible data types like for the services. A dedicated DIM name-server takes control over all the running clients, servers and their services available in the system. Each server registers at startup all its services and command channels. For a client the location of a server is transparent. It asks the DIM name-server which server provides a specific service and retrieves the access information. The process then connects directly to the corresponding server. The DIM name-server concept eases a recovery process of the system after update and restart of servers or clients at any time. It enables also fast migration from one machine to another and distributed tasks. Whenever one of the processes (a server or even the name server) in the system crashes or dies all processes connected to it will be notified and will reconnect as soon as it comes back to life. === PVSS === === InterComLayer === The InterComLayer takes the task of the Control Layer. It runs independently from the other system layers on a separate machine outside of the radiation area. It provides three interfaces: * Front-End-Electronics Client (DIM client) to connect to the Field Layer * Front-End-Device Server (DIM server) to connect to the Supervisory Layer * Interface to the Configuration Database, using a database client [[Image:FeeCom-Software.png|frame|none|The InterCom layer in the data flow of the FeeCommunication software.]] The FEE interface consists of a command channel, a corresponding acknowledge channel, a message channel and several service channels. These services are referred to be values of interest like temperature, voltage, currents, etc. of the Front-end electronics. In order to reduce network traffic the FeeServer can apply thresholds for data value changes, so called dead-bands. Changes are only published if a certain dead-band is exceeded, the dead-band can be defined for each service independently in conformity with the different nature of the data. The InterComLayer connects to FeeServers according to the configuration. After the connection is established, the InterComLayer subscribes to the services of the FeeServers and controls their message channels. Filtering of messages according to the log-level is performed on each layer to reduce network traffic. The service channels of the FeeServers are pooled together and re-published to the supervisory level. By this means the source of the services is transparent to the SCADA system on top. The InterComLayer is an abstraction layer, which disconnects Supervisory and Field Layer. In order to transport configuration data to the Front-end electronics, the InterComLayer has an interface to the configuration database. Neither database nor InterComLayer know about the format of the data. The data will be handled as BLOBs (Binary Large OBjects). The database contains entries of configuration packages. For each specific configuration of the Front-end electronics it creates a descriptor which refers to the required configuration packages. The Supervisory Layer sends a request to load a certain configuration to the InterComLayer, which then fetches the corresponding ''BLOB'' from the configuration database and transports it through the command channel to the FeeServers. In addition, the InterComLayer provides functionality for maintenance and control of the FeeServers. Servers can be updated, restarted and their controlling properties can be adjusted to any requirements. For further details go to the [[InterCom Layer]] page. ==== Compiliation and Installation ==== It exists a dedicated description for compiling and installing the [[InterComLayer installation]]. === The Front-End-Electronics-Server === The DCS for the Front-end elctronics is based on so called Front-End-Electronics-Servers (FeeServers), which are running on the DCS board close to the hardware. A FeeServer abstracts the underlying Front-end electronics to a certain degree and covers the following tasks: * Interfacing hardware data sources and publishing data * Receiving of commands and configuration data for controlling the Front-end electronics * Self-tests and Watchdogs (consistency check and setting of parameters) In order to keep development simple and the software re-usable for different hardware setups the FeeServer has been splitted into a device independent core and an interface to the hardware dependent functionality. It exists a dedicated description for compiling and installing the [[FeeServer]], as well as some hints and guidelines for developing an own [[FeeServer#ControlEngine guidelines|ControlEngine]] (CE) for the FeeServer. ==== The FeeServer core ==== The core of the FeeServer is device-independent. It provides general communication functionality, remote control and update of the whole FeeServer application. Some features are related to the configuration of the data publishing. In order to reduce network traffic, variable deadbands have been introduced. Data is only updated if the variation exceeds the deadband. The core can be used for different devices, i.e. different detectors of the ALICE experiment. The device-dependent actions are adapted for each specific device and are executed in separated threads. This makes a controlled execution possible. If execution is stuck, the server core is still running independently. It can kill and clean up the stuck thread and notify the upper layers. ==== The ControlEngine (CE) ==== The ControlEngine implements the device dependent functionality of the FeeServer. The CE provides data access in order to monitor data points and executes received commands specific for the underlying hardware. An abstract interface between FeeServer and CE is defined, the ControlEngine implements interface methods for initializing, cleaning up and command execution. It has contact to the specific bus systems of the hardware devices. The access is ancapsulated in Linux device drivers. This makes the functionality of the CE independent from the hardware/firmware version. One example is the CE for the TPC detector and the RCU. Please check the dedicated site [[RCU ControlEngine]]. === DCS board tools === This sections covers the DCS board software for the TPC-like detectors (so far TPC, PHOS, most likely FMD and EMCAL). Apart from the mentioned FeeServer there are some low level tools and interfaces. In fact, the FeeServer uses them. ...[[DCS board tools| read more]]. == Specifications == === Front-End-Device interface === The FED API is common among all detectors in ALICE. It defines the interface between the FedServer(s) and the PVSS system of one detector. A more detailed description you will find in the document itself. This is the version currently (03.02.2006) also available at the DCS pages: [http://www.ift.uib.no/~kjeks/download/documents/FedServerAPI-v2.0.pdf FED API v2.0 (draft)] === Front-End-Electronics interface === === Control Engine interface === === [[DCS_board_tools#Message_Buffer_access_.28RCU_interface.29 | Message Buffer Interface]] === === [[RCU ControlEngine]] === === Format of TPC configuration data === == [[DCS FAQ]] == == [[DCS Download]] == == [[DCS Tutorial|How to set up a FeeCom chain]]== == [[Setup of low-level DCS for TPC Front-end electronics]]== == [[Setting up a local DCS network]]== == [[Documentation of different FeeServer Control Engines]] == == Links == * [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc The ALICE TPC Front End Electronics] * [http://alicedcs.web.cern.ch/AliceDCS/ ALICE Detector Control System group] * [http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/ The DCS board pages] * [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html ARM linux on the DCS board] * [http://www.ztt.fh-worms.de/en/projects/Alice-FEEControl/index.shtml FeeCom Software] * [http://www.cern.ch/dim Distributed Information Management System (DIM)] ---- ---- [[Category:DCS]] 2083d9fd87b6d59e85d81ff251bd4d0b4b367ac2 0 194 613 2009-07-07T11:21:53Z Dfe002 7 Created page with '==Busybox FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== ==Laser Sync FeeServer== ===Services=== *MODEFREQVAL *FLASHEKSPLASTAR...' wikitext text/x-wiki ==Busybox FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== ==Laser Sync FeeServer== ===Services=== *MODEFREQVAL *FLASHEKSPLASTARTTIME *FLASHEKSPLAENDTIME *FLASHSPECTRONSTARTTIME *FLASHSPECTRONENDTIME *SPECTRONDELAY *L0REQUESTTIME *L0RETURNWINDOWSTART *L0RETURNWINDOWSTOP *QSWITCHEKSPLASTART *QSWITCHEKSPLASTOP *RUNMODE *SAMPLECLOCKDIVIDER *TRIGGERCONFIGURATION1 *TRIGGERCONFIGURATION2 *RCUVERSION *CTPSIGNATURE *SHUTTERCOUNTER *EKSPLAFLASHCOUNTER *SPECTRONFLASHCOUNTER *EKSPLAQSWITCHCOUNTER *SPECTRONQSWITCHCOUNTER *L0REQUESTCOUNTER *L0RECEIVEDCOUNTER *L0RECEIVEDINWINDOWCOUNTER *L0TIMEOUTCOUNTER *L0RETURNTIMER *ACTUALLASERRATE *CYCLETIMER *TTC_CONTROL *TTC_ROICONFIG1 *TTC_ROICONFIG2 *TTC_L1LATENCY *TTC_L2LATENCY *TTC_ROILATENCY *TTC_L1MSGLATENCY *TTC_PREPULSECNT *TTC_BCIDLOCAL *TTC_L0COUNTER *TTC_L1MSGCOUNTER *TTC_L2ACOUNTER *TTC_L2RCOUNTER *TTC_ROICOUNTER *TTC_HAMMINGERRCNT *TTC_ERRORCNT *TTC_BUFFEREDEVENTS *TTC_DAQHEADER1 *TTC_DAQHEADER2 *TTC_DAQHEADER3 *TTC_DAQHEADER4 *TTC_DAQHEADER5 *TTC_DAQHEADER6 *TTC_DAQHEADER7 *TTC_EVENTINFO ===Commands=== ====Hex Commands==== *LASER_WRITE_MODEFREQVAL (0xFD010000) *LASER_WRITE_FLASHEKSPLASTARTTIME (0xFD020000) *LASER_WRITE_FLASHEKSPLAENDTIME (0xFD030000) *LASER_WRITE_FLASHSPECTRONSTARTTIME (0xFD040000) *LASER_WRITE_FLASHSPECTRONENDTIME (0xFD050000) *LASER_WRITE_SPECTRONDELAY (0xFD060000) *LASER_WRITE_L0REQUESTTIME (0xFD070000) *LASER_WRITE_L0RETURNWINDOWSTART (0xFD080000) *LASER_WRITE_L0RETURNWINDOWSTOP (0xFD090000) *LASER_WRITE_QSWITCHEKSPLASTART (0xFD0A0000) *LASER_WRITE_QSWITCHEKSPLASTOP (0xFD0B0000) *LASER_WRITE_RUNMODE (0xFD0C0000) *LASER_WRITE_SAMPLECLOCKDIVIDER (0xFD0D0000) *LASER_WRITE_TRIGGERCONFIGURATION1 (0xFD0E0000) *LASER_WRITE_TRIGGERCONFIGURATION2 (0xFD0F0000) *LASER_WRITE_TTC_CONTROL (0xFD110000) *LASER_TOGGLE_TTC_RESET (0xFD120000) *LASER_WRITE_TTC_ROICONFIG1 (0xFD130000) *LASER_WRITE_TTC_ROICONFIG2 (0xFD140000) *LASER_TOGGLE_TTC_RESETCOUNTER (0xFD150000) *LASER_TOGGLE_TTC_ISSUETESTMODE (0xFD160000) *LASER_WRITE_TTC_L1LATENCY (0xFD170000) *LASER_WRITE_TTC_L2LATENCY (0xFD180000) *LASER_WRITE_TTC_ROILATENCY (0xFD190000) *LASER_WRITE_TTC_L1MSGLATENCY (0xFD1A0000) * LASER_SET_FLASHEKSPLASTARTTIME (0xFD1B0000 ) * LASER_SET_FLASHEKSPLAENDTIME (0xFD1C0000 ) * LASER_SET_SPECTRONSTARTTIME (0xFD1D0000 ) * LASER_SET_SPECTRONENDTIME (0xFD1E0000 ) * LASER_SET_SPECTRONDELAY (0xFD1F0000 ) * LASER_SET_L0REQUESTTIME (0xFD200000 ) * LASER_SET_L0RETURNWINDOWSTART (0xFD210000 ) * LASER_SET_L0RETURNWINDOWEND (0xFD220000 ) * LASER_SET_QSWITCHEKSPLASTART (0xFD230000 ) * LASER_SET_QSWITCHEKSPLAEND (0xFD240000 ) * LASER_CLEAR_COUNTERS (0xFD250000 ) ====Highlevel Commands==== *LASER_WRITE_MODEFREQVAL *LASER_WRITE_FLASHEKSPLASTARTTIME *LASER_WRITE_FLASHEKSPLAENDTIME LASER_WRITE_FLASHSPECTRONSTARTTIME *LASER_WRITE_FLASHSPECTRONENDTIME *LASER_WRITE_SPECTRONDELAY *LASER_WRITE_L0REQUESTTIME *LASER_WRITE_L0RETURNWINDOWSTART *LASER_WRITE_L0RETURNWINDOWSTOP *LASER_WRITE_QSWITCHEKSPLASTART *LASER_WRITE_QSWITCHEKSPLASTOP *LASER_WRITE_RUNMODE *LASER_WRITE_SAMPLECLOCKDIVIDER *LASER_WRITE_TRIGGERCONFIGURATION1 *LASER_WRITE_TRIGGERCONFIGURATION2 *LASER_WRITE_TTC_CONTROL *LASER_TOGGLE_TTC_RESET *LASER_WRITE_TTC_ROICONFIG1 *LASER_WRITE_TTC_ROICONFIG2 *LASER_TOGGLE_TTC_RESETCOUNTER *LASER_TOGGLE_TTC_ISSUETESTMODE *LASER_WRITE_TTC_L2LATENCY *LASER_WRITE_TTC_L1LATENCY *LASER_WRITE_TTC_ROILATENCY *LASER_WRITE_TTC_L1MSGLATENCY *LASER_SET_FLASHEKSPLASTARTTIME (Shuttertime, Flash Ekspla Time, Shift) *LASER_SET_FLASHEKSPLAENDTIME (Shuttertime, Flash Ekspla Time, Flash Ekspla duration, Shift) *LASER_SET_SPECTRONSTARTTIME (Shuttertime, Spectron Flash Time, Shift) *LASER_SET_SPECTRONENDTIME (Shuttertime, Spectron Flash Time, Spectron QSwitch Time, Shift) *LASER_SET_SPECTRONDELAY (Spectron QSwitch Veto Delay) *LASER_SET_L0REQUESTTIME (Shuttertime, L0Time, Shift) *LASER_SET_L0RETURNWINDOWSTART (Shuttertime, L0Time, L0 Window start, shift) *LASER_SET_L0RETURNWINDOWEND (Shuttertime, L0Time, L0 Window start, L0 Window end, shift) *LASER_SET_QSWITCHEKSPLASTART (Shuttertime, QSwitch Ekspla time, shift) *LASER_SET_QSWITCHEKSPLAEND (Shuttertime, QSwitch Ekspla time, QSwitch Ekspla duration, shift) *LASER_CLEAR_COUNTERS() ===States and Transitions=== ==Gating Pulser FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== ==RCU FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== 10184a701161d55d9758069da96af04cfe62d0cd 614 613 2009-07-07T11:24:11Z Dfe002 7 wikitext text/x-wiki ==Busybox FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== ==Laser Sync FeeServer== ===Services=== *MODEFREQVAL *FLASHEKSPLASTARTTIME *FLASHEKSPLAENDTIME *FLASHSPECTRONSTARTTIME *FLASHSPECTRONENDTIME *SPECTRONDELAY *L0REQUESTTIME *L0RETURNWINDOWSTART *L0RETURNWINDOWSTOP *QSWITCHEKSPLASTART *QSWITCHEKSPLASTOP *RUNMODE *SAMPLECLOCKDIVIDER *TRIGGERCONFIGURATION1 *TRIGGERCONFIGURATION2 *RCUVERSION *CTPSIGNATURE *SHUTTERCOUNTER *EKSPLAFLASHCOUNTER *SPECTRONFLASHCOUNTER *EKSPLAQSWITCHCOUNTER *SPECTRONQSWITCHCOUNTER *L0REQUESTCOUNTER *L0RECEIVEDCOUNTER *L0RECEIVEDINWINDOWCOUNTER *L0TIMEOUTCOUNTER *L0RETURNTIMER *ACTUALLASERRATE *CYCLETIMER *TTC_CONTROL *TTC_ROICONFIG1 *TTC_ROICONFIG2 *TTC_L1LATENCY *TTC_L2LATENCY *TTC_ROILATENCY *TTC_L1MSGLATENCY *TTC_PREPULSECNT *TTC_BCIDLOCAL *TTC_L0COUNTER *TTC_L1MSGCOUNTER *TTC_L2ACOUNTER *TTC_L2RCOUNTER *TTC_ROICOUNTER *TTC_HAMMINGERRCNT *TTC_ERRORCNT *TTC_BUFFEREDEVENTS *TTC_DAQHEADER1 *TTC_DAQHEADER2 *TTC_DAQHEADER3 *TTC_DAQHEADER4 *TTC_DAQHEADER5 *TTC_DAQHEADER6 *TTC_DAQHEADER7 *TTC_EVENTINFO ===Commands=== ====Hex Commands==== *LASER_WRITE_MODEFREQVAL (0xFD010000) *LASER_WRITE_FLASHEKSPLASTARTTIME (0xFD020000) *LASER_WRITE_FLASHEKSPLAENDTIME (0xFD030000) *LASER_WRITE_FLASHSPECTRONSTARTTIME (0xFD040000) *LASER_WRITE_FLASHSPECTRONENDTIME (0xFD050000) *LASER_WRITE_SPECTRONDELAY (0xFD060000) *LASER_WRITE_L0REQUESTTIME (0xFD070000) *LASER_WRITE_L0RETURNWINDOWSTART (0xFD080000) *LASER_WRITE_L0RETURNWINDOWSTOP (0xFD090000) *LASER_WRITE_QSWITCHEKSPLASTART (0xFD0A0000) *LASER_WRITE_QSWITCHEKSPLASTOP (0xFD0B0000) *LASER_WRITE_RUNMODE (0xFD0C0000) *LASER_WRITE_SAMPLECLOCKDIVIDER (0xFD0D0000) *LASER_WRITE_TRIGGERCONFIGURATION1 (0xFD0E0000) *LASER_WRITE_TRIGGERCONFIGURATION2 (0xFD0F0000) *LASER_WRITE_TTC_CONTROL (0xFD110000) *LASER_TOGGLE_TTC_RESET (0xFD120000) *LASER_WRITE_TTC_ROICONFIG1 (0xFD130000) *LASER_WRITE_TTC_ROICONFIG2 (0xFD140000) *LASER_TOGGLE_TTC_RESETCOUNTER (0xFD150000) *LASER_TOGGLE_TTC_ISSUETESTMODE (0xFD160000) *LASER_WRITE_TTC_L1LATENCY (0xFD170000) *LASER_WRITE_TTC_L2LATENCY (0xFD180000) *LASER_WRITE_TTC_ROILATENCY (0xFD190000) *LASER_WRITE_TTC_L1MSGLATENCY (0xFD1A0000) * LASER_SET_FLASHEKSPLASTARTTIME (0xFD1B0000 ) * LASER_SET_FLASHEKSPLAENDTIME (0xFD1C0000 ) * LASER_SET_SPECTRONSTARTTIME (0xFD1D0000 ) * LASER_SET_SPECTRONENDTIME (0xFD1E0000 ) * LASER_SET_SPECTRONDELAY (0xFD1F0000 ) * LASER_SET_L0REQUESTTIME (0xFD200000 ) * LASER_SET_L0RETURNWINDOWSTART (0xFD210000 ) * LASER_SET_L0RETURNWINDOWEND (0xFD220000 ) * LASER_SET_QSWITCHEKSPLASTART (0xFD230000 ) * LASER_SET_QSWITCHEKSPLAEND (0xFD240000 ) * LASER_CLEAR_COUNTERS (0xFD250000 ) ====Highlevel Commands==== *LASER_WRITE_MODEFREQVAL *LASER_WRITE_FLASHEKSPLASTARTTIME *LASER_WRITE_FLASHEKSPLAENDTIME LASER_WRITE_FLASHSPECTRONSTARTTIME *LASER_WRITE_FLASHSPECTRONENDTIME *LASER_WRITE_SPECTRONDELAY *LASER_WRITE_L0REQUESTTIME *LASER_WRITE_L0RETURNWINDOWSTART *LASER_WRITE_L0RETURNWINDOWSTOP *LASER_WRITE_QSWITCHEKSPLASTART *LASER_WRITE_QSWITCHEKSPLASTOP *LASER_WRITE_RUNMODE *LASER_WRITE_SAMPLECLOCKDIVIDER *LASER_WRITE_TRIGGERCONFIGURATION1 *LASER_WRITE_TRIGGERCONFIGURATION2 *LASER_WRITE_TTC_CONTROL *LASER_TOGGLE_TTC_RESET *LASER_WRITE_TTC_ROICONFIG1 *LASER_WRITE_TTC_ROICONFIG2 *LASER_TOGGLE_TTC_RESETCOUNTER *LASER_TOGGLE_TTC_ISSUETESTMODE *LASER_WRITE_TTC_L2LATENCY *LASER_WRITE_TTC_L1LATENCY *LASER_WRITE_TTC_ROILATENCY *LASER_WRITE_TTC_L1MSGLATENCY *LASER_SET_FLASHEKSPLASTARTTIME (Shuttertime, Flash Ekspla Time, Shift) *LASER_SET_FLASHEKSPLAENDTIME (Shuttertime, Flash Ekspla Time, Flash Ekspla duration, Shift) *LASER_SET_SPECTRONSTARTTIME (Shuttertime, Spectron Flash Time, Shift) *LASER_SET_SPECTRONENDTIME (Shuttertime, Spectron Flash Time, Spectron QSwitch Time, Shift) *LASER_SET_SPECTRONDELAY (Spectron QSwitch Veto Delay) *LASER_SET_L0REQUESTTIME (Shuttertime, L0Time, Shift) *LASER_SET_L0RETURNWINDOWSTART (Shuttertime, L0Time, L0 Window start, shift) *LASER_SET_L0RETURNWINDOWEND (Shuttertime, L0Time, L0 Window start, L0 Window end, shift) *LASER_SET_QSWITCHEKSPLASTART (Shuttertime, QSwitch Ekspla time, shift) *LASER_SET_QSWITCHEKSPLAEND (Shuttertime, QSwitch Ekspla time, QSwitch Ekspla duration, shift) *LASER_CLEAR_COUNTERS() ===States and Transitions=== Transitions: * LOAD_RECIPE * GO_STANDBY * GO_WARM_UP * GO_ON_FREE_RUN * GO_ON_TRIGGER * GO_STBY_CONFIGURED * GO_STBY_CONFIGURED States: *STANDBY *STBY_CONFIGURED *WARM_UP *ON_TRIGGER *ON_FREE_RUN ==Gating Pulser FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== ==RCU FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== 5ec353818427d54f677e8bb463a3a654ea175eb9 615 614 2009-07-07T11:35:45Z Dfe002 7 wikitext text/x-wiki ==Busybox FeeServer== ===Services=== TXR RXMP EIDFIFOC CEID0 CEID1 CEID2 MREID0 MREID1 MREID2 L0TTO FEEBA FSMH RRTO CRID RC BT0 BT1 RXMF TMC0 TMC1 L0L BCIDO L1C L2AC L2RC ===Commands=== ====Hex Commands==== #define FEESVR_CMD_BB (0x0c000000 | FEESERVER_CMD) #define BB_INIT (0x010000 | FEESVR_CMD_BB) #define INIT_BUSY_BOX (0x010000 | FEESVR_CMD_BB) //Depricated #define BB_WRITE_STATUS (0x020000 | FEESVR_CMD_BB) #define BB_WRITE_RXMF (0x030000 | FEESVR_CMD_BB) #define BB_WRITE_RRTO (0x040000 | FEESVR_CMD_BB) #define BB_WRITE_FM (0x050000 | FEESVR_CMD_BB) #define BB_WRITE_FSMH (0x060000 | FEESVR_CMD_BB) #define BB_WRITE_FEEBA (0x070000 | FEESVR_CMD_BB) #define BB_WRITE_L0TTO (0x080000 | FEESVR_CMD_BB) #define BB_WRITE_L0_TIMEOUT (0x080000 | FEESVR_CMD_BB) //Depricated #define BB_WRITE_TX (0x090000 | FEESVR_CMD_BB) #define BB_WRITE_TMC0 (0x0a0000 | FEESVR_CMD_BB) #define BB_WRITE_TMC1 (0x0b0000 | FEESVR_CMD_BB) #define BB_WRITE_TMR (0x0c0000 | FEESVR_CMD_BB) #define BB_WRITE_L0L (0x0d0000 | FEESVR_CMD_BB) #define BB_WRITE_BCIDO (0x0e0000 | FEESVR_CMD_BB) #define BB_FIRMWARE_RESET (0x0f0000 | FEESVR_CMD_BB) ====Highlevel Commands==== BB_WRITE_TX BB_WRITE_L0TTO BB_WRITE_FEEBA BB_WRITE_FSMH BB_WRITE_FM BB_WRITE_RRTO BB_WRITE_RXMF ===States and Transitions=== ==Laser Sync FeeServer== ===Services=== *MODEFREQVAL *FLASHEKSPLASTARTTIME *FLASHEKSPLAENDTIME *FLASHSPECTRONSTARTTIME *FLASHSPECTRONENDTIME *SPECTRONDELAY *L0REQUESTTIME *L0RETURNWINDOWSTART *L0RETURNWINDOWSTOP *QSWITCHEKSPLASTART *QSWITCHEKSPLASTOP *RUNMODE *SAMPLECLOCKDIVIDER *TRIGGERCONFIGURATION1 *TRIGGERCONFIGURATION2 *RCUVERSION *CTPSIGNATURE *SHUTTERCOUNTER *EKSPLAFLASHCOUNTER *SPECTRONFLASHCOUNTER *EKSPLAQSWITCHCOUNTER *SPECTRONQSWITCHCOUNTER *L0REQUESTCOUNTER *L0RECEIVEDCOUNTER *L0RECEIVEDINWINDOWCOUNTER *L0TIMEOUTCOUNTER *L0RETURNTIMER *ACTUALLASERRATE *CYCLETIMER *TTC_CONTROL *TTC_ROICONFIG1 *TTC_ROICONFIG2 *TTC_L1LATENCY *TTC_L2LATENCY *TTC_ROILATENCY *TTC_L1MSGLATENCY *TTC_PREPULSECNT *TTC_BCIDLOCAL *TTC_L0COUNTER *TTC_L1MSGCOUNTER *TTC_L2ACOUNTER *TTC_L2RCOUNTER *TTC_ROICOUNTER *TTC_HAMMINGERRCNT *TTC_ERRORCNT *TTC_BUFFEREDEVENTS *TTC_DAQHEADER1 *TTC_DAQHEADER2 *TTC_DAQHEADER3 *TTC_DAQHEADER4 *TTC_DAQHEADER5 *TTC_DAQHEADER6 *TTC_DAQHEADER7 *TTC_EVENTINFO ===Commands=== ====Hex Commands==== *LASER_WRITE_MODEFREQVAL (0xFD010000) *LASER_WRITE_FLASHEKSPLASTARTTIME (0xFD020000) *LASER_WRITE_FLASHEKSPLAENDTIME (0xFD030000) *LASER_WRITE_FLASHSPECTRONSTARTTIME (0xFD040000) *LASER_WRITE_FLASHSPECTRONENDTIME (0xFD050000) *LASER_WRITE_SPECTRONDELAY (0xFD060000) *LASER_WRITE_L0REQUESTTIME (0xFD070000) *LASER_WRITE_L0RETURNWINDOWSTART (0xFD080000) *LASER_WRITE_L0RETURNWINDOWSTOP (0xFD090000) *LASER_WRITE_QSWITCHEKSPLASTART (0xFD0A0000) *LASER_WRITE_QSWITCHEKSPLASTOP (0xFD0B0000) *LASER_WRITE_RUNMODE (0xFD0C0000) *LASER_WRITE_SAMPLECLOCKDIVIDER (0xFD0D0000) *LASER_WRITE_TRIGGERCONFIGURATION1 (0xFD0E0000) *LASER_WRITE_TRIGGERCONFIGURATION2 (0xFD0F0000) *LASER_WRITE_TTC_CONTROL (0xFD110000) *LASER_TOGGLE_TTC_RESET (0xFD120000) *LASER_WRITE_TTC_ROICONFIG1 (0xFD130000) *LASER_WRITE_TTC_ROICONFIG2 (0xFD140000) *LASER_TOGGLE_TTC_RESETCOUNTER (0xFD150000) *LASER_TOGGLE_TTC_ISSUETESTMODE (0xFD160000) *LASER_WRITE_TTC_L1LATENCY (0xFD170000) *LASER_WRITE_TTC_L2LATENCY (0xFD180000) *LASER_WRITE_TTC_ROILATENCY (0xFD190000) *LASER_WRITE_TTC_L1MSGLATENCY (0xFD1A0000) * LASER_SET_FLASHEKSPLASTARTTIME (0xFD1B0000 ) * LASER_SET_FLASHEKSPLAENDTIME (0xFD1C0000 ) * LASER_SET_SPECTRONSTARTTIME (0xFD1D0000 ) * LASER_SET_SPECTRONENDTIME (0xFD1E0000 ) * LASER_SET_SPECTRONDELAY (0xFD1F0000 ) * LASER_SET_L0REQUESTTIME (0xFD200000 ) * LASER_SET_L0RETURNWINDOWSTART (0xFD210000 ) * LASER_SET_L0RETURNWINDOWEND (0xFD220000 ) * LASER_SET_QSWITCHEKSPLASTART (0xFD230000 ) * LASER_SET_QSWITCHEKSPLAEND (0xFD240000 ) * LASER_CLEAR_COUNTERS (0xFD250000 ) ====Highlevel Commands==== *LASER_WRITE_MODEFREQVAL *LASER_WRITE_FLASHEKSPLASTARTTIME *LASER_WRITE_FLASHEKSPLAENDTIME LASER_WRITE_FLASHSPECTRONSTARTTIME *LASER_WRITE_FLASHSPECTRONENDTIME *LASER_WRITE_SPECTRONDELAY *LASER_WRITE_L0REQUESTTIME *LASER_WRITE_L0RETURNWINDOWSTART *LASER_WRITE_L0RETURNWINDOWSTOP *LASER_WRITE_QSWITCHEKSPLASTART *LASER_WRITE_QSWITCHEKSPLASTOP *LASER_WRITE_RUNMODE *LASER_WRITE_SAMPLECLOCKDIVIDER *LASER_WRITE_TRIGGERCONFIGURATION1 *LASER_WRITE_TRIGGERCONFIGURATION2 *LASER_WRITE_TTC_CONTROL *LASER_TOGGLE_TTC_RESET *LASER_WRITE_TTC_ROICONFIG1 *LASER_WRITE_TTC_ROICONFIG2 *LASER_TOGGLE_TTC_RESETCOUNTER *LASER_TOGGLE_TTC_ISSUETESTMODE *LASER_WRITE_TTC_L2LATENCY *LASER_WRITE_TTC_L1LATENCY *LASER_WRITE_TTC_ROILATENCY *LASER_WRITE_TTC_L1MSGLATENCY *LASER_SET_FLASHEKSPLASTARTTIME (Shuttertime, Flash Ekspla Time, Shift) *LASER_SET_FLASHEKSPLAENDTIME (Shuttertime, Flash Ekspla Time, Flash Ekspla duration, Shift) *LASER_SET_SPECTRONSTARTTIME (Shuttertime, Spectron Flash Time, Shift) *LASER_SET_SPECTRONENDTIME (Shuttertime, Spectron Flash Time, Spectron QSwitch Time, Shift) *LASER_SET_SPECTRONDELAY (Spectron QSwitch Veto Delay) *LASER_SET_L0REQUESTTIME (Shuttertime, L0Time, Shift) *LASER_SET_L0RETURNWINDOWSTART (Shuttertime, L0Time, L0 Window start, shift) *LASER_SET_L0RETURNWINDOWEND (Shuttertime, L0Time, L0 Window start, L0 Window end, shift) *LASER_SET_QSWITCHEKSPLASTART (Shuttertime, QSwitch Ekspla time, shift) *LASER_SET_QSWITCHEKSPLAEND (Shuttertime, QSwitch Ekspla time, QSwitch Ekspla duration, shift) *LASER_CLEAR_COUNTERS() ===States and Transitions=== Transitions: * LOAD_RECIPE * GO_STANDBY * GO_WARM_UP * GO_ON_FREE_RUN * GO_ON_TRIGGER * GO_STBY_CONFIGURED * GO_STBY_CONFIGURED States: *STANDBY *STBY_CONFIGURED *WARM_UP *ON_TRIGGER *ON_FREE_RUN ==TOR FeeServer== ===Services=== TME 1DSFRL0 1DSFRL1L 1DSFRL1M 1DSFRL1H EDTORO IDELAY EDTRUIB0B1 EDTRUIB2B3 EDTRUIB4 LVDSIGB0B1 LVDSIGB2B3 LVDSIGB4 ===Commands=== ====Highlevel Commands==== TOR_WRITE_TME TOR_WRITE_1DSFRL0 TOR_WRITE_1DSFRL1L TOR_WRITE_1DSFRL1M TOR_WRITE_1DSFRL1H TOR_WRITE_EDTORO TOR_WRITE_IDELAY TOR_WRITE_EDTRUIB0B1 TOR_WRITE_EDTRUIB2B3 TOR_WRITE_EDTRUIB4 ====Hex Commands==== #define FEESVR_CMD_TOR (0x0e000000 | FEESERVER_CMD) #define TOR_WRITE_TME (0x010000 | FEESVR_CMD_BB) #define TOR_WRITE_1DSFRL0 (0x020000 | FEESVR_CMD_BB) #define TOR_WRITE_1DSFRL1L (0x030000 | FEESVR_CMD_BB) #define TOR_WRITE_1DSFRL1M (0x040000 | FEESVR_CMD_BB) #define TOR_WRITE_1DSFRL1H (0x050000 | FEESVR_CMD_BB) #define TOR_WRITE_EDTORO (0x060000 | FEESVR_CMD_BB) #define TOR_WRITE_IDELAY (0x070000 | FEESVR_CMD_BB) #define TOR_WRITE_EDTRUIB0B1 (0x080000 | FEESVR_CMD_BB) #define TOR_WRITE_EDTRUIB2B3 (0x090000 | FEESVR_CMD_BB) #define TOR_WRITE_EDTRUIB4 (0x0a0000 | FEESVR_CMD_BB) ===States and Transitions=== ==Gating Pulser FeeServer== ===Services=== CONFREG FWVERSION PULSESTATUS PULSECOUNTER FSMSTREG ===Commands=== ====Highlevel Commands==== GPULSER_WRITE_CONFREG; GPULSER_TOGGLE_RESET; GPULSER_TOGGLE_GLOBAL_RESET; GPULSER_WRITE_TTC_CONTROL; GPULSER_TOGGLE_TTC_RESET; GPULSER_WRITE_TTC_ROICONFIG1; GPULSER_WRITE_TTC_ROICONFIG2; GPULSER_TOGGLE_TTC_RESETCOUNTER; GPULSER_TOGGLE_TTC_ISSUETESTMODE; GPULSER_WRITE_TTC_L2LATENCY; GPULSER_WRITE_TTC_L1LATENCY; GPULSER_WRITE_TTC_ROILATENCY; GPULSER_WRITE_TTC_L1MSGLATENCY; ====Hex Commands==== #define FEESVR_CMD_GPULSER (0x0f000000 | FEESERVER_CMD) #define GPULSER_WRITE_TTC_CONTROL (0x100000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_TTC_RESET (0x200000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_ROICONFIG1 (0x300000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_ROICONFIG2 (0x400000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_TTC_RESETCOUNTER (0x500000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_TTC_ISSUETESTMODE (0x600000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_L1LATENCY (0x700000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_L2LATENCY (0x800000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_ROILATENCY (0x900000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_L1MSGLATENCY (0xA00000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_RESET (0xB00000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_GLOBAL_RESET (0xC00000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_CONFREG (0xD00000 | FEESVR_CMD_GPULSER) ===States and Transitions=== ==RCU FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== bd206ca7ed90550acea4852438cca10f66577efe 616 615 2009-07-07T11:38:18Z Dfe002 7 wikitext text/x-wiki ==Busybox FeeServer== ===Services=== *TXR *RXMP *EIDFIFOC *CEID0 *CEID1 *CEID2 *MREID0 *MREID1 *MREID2 *L0TTO *FEEBA *FSMH *RRTO *CRID *RC *BT0 *BT1 *RXMF *TMC0 *TMC1 *L0L *BCIDO *L1C *L2AC *L2RC ===Commands=== ====Hex Commands==== *FEESVR_CMD_BB (0x0c000000 | FEESERVER_CMD) *BB_INIT (0x010000 | FEESVR_CMD_BB) *INIT_BUSY_BOX (0x010000 | FEESVR_CMD_BB) //Depricated *BB_WRITE_STATUS (0x020000 | FEESVR_CMD_BB) *BB_WRITE_RXMF (0x030000 | FEESVR_CMD_BB) *BB_WRITE_RRTO (0x040000 | FEESVR_CMD_BB) *BB_WRITE_FM (0x050000 | FEESVR_CMD_BB) *BB_WRITE_FSMH (0x060000 | FEESVR_CMD_BB) *BB_WRITE_FEEBA (0x070000 | FEESVR_CMD_BB) *BB_WRITE_L0TTO (0x080000 | FEESVR_CMD_BB) *BB_WRITE_L0_TIMEOUT (0x080000 | FEESVR_CMD_BB) //Depricated *BB_WRITE_TX (0x090000 | FEESVR_CMD_BB) *BB_WRITE_TMC0 (0x0a0000 | FEESVR_CMD_BB) *BB_WRITE_TMC1 (0x0b0000 | FEESVR_CMD_BB) *BB_WRITE_TMR (0x0c0000 | FEESVR_CMD_BB) *BB_WRITE_L0L (0x0d0000 | FEESVR_CMD_BB) *BB_WRITE_BCIDO (0x0e0000 | FEESVR_CMD_BB) *BB_FIRMWARE_RESET (0x0f0000 | FEESVR_CMD_BB) ====Highlevel Commands==== *BB_WRITE_TX *BB_WRITE_L0TTO *BB_WRITE_FEEBA *BB_WRITE_FSMH *BB_WRITE_FM *BB_WRITE_RRTO *BB_WRITE_RXMF ===States and Transitions=== ==Laser Sync FeeServer== ===Services=== *MODEFREQVAL *FLASHEKSPLASTARTTIME *FLASHEKSPLAENDTIME *FLASHSPECTRONSTARTTIME *FLASHSPECTRONENDTIME *SPECTRONDELAY *L0REQUESTTIME *L0RETURNWINDOWSTART *L0RETURNWINDOWSTOP *QSWITCHEKSPLASTART *QSWITCHEKSPLASTOP *RUNMODE *SAMPLECLOCKDIVIDER *TRIGGERCONFIGURATION1 *TRIGGERCONFIGURATION2 *RCUVERSION *CTPSIGNATURE *SHUTTERCOUNTER *EKSPLAFLASHCOUNTER *SPECTRONFLASHCOUNTER *EKSPLAQSWITCHCOUNTER *SPECTRONQSWITCHCOUNTER *L0REQUESTCOUNTER *L0RECEIVEDCOUNTER *L0RECEIVEDINWINDOWCOUNTER *L0TIMEOUTCOUNTER *L0RETURNTIMER *ACTUALLASERRATE *CYCLETIMER *TTC_CONTROL *TTC_ROICONFIG1 *TTC_ROICONFIG2 *TTC_L1LATENCY *TTC_L2LATENCY *TTC_ROILATENCY *TTC_L1MSGLATENCY *TTC_PREPULSECNT *TTC_BCIDLOCAL *TTC_L0COUNTER *TTC_L1MSGCOUNTER *TTC_L2ACOUNTER *TTC_L2RCOUNTER *TTC_ROICOUNTER *TTC_HAMMINGERRCNT *TTC_ERRORCNT *TTC_BUFFEREDEVENTS *TTC_DAQHEADER1 *TTC_DAQHEADER2 *TTC_DAQHEADER3 *TTC_DAQHEADER4 *TTC_DAQHEADER5 *TTC_DAQHEADER6 *TTC_DAQHEADER7 *TTC_EVENTINFO ===Commands=== ====Hex Commands==== *LASER_WRITE_MODEFREQVAL (0xFD010000) *LASER_WRITE_FLASHEKSPLASTARTTIME (0xFD020000) *LASER_WRITE_FLASHEKSPLAENDTIME (0xFD030000) *LASER_WRITE_FLASHSPECTRONSTARTTIME (0xFD040000) *LASER_WRITE_FLASHSPECTRONENDTIME (0xFD050000) *LASER_WRITE_SPECTRONDELAY (0xFD060000) *LASER_WRITE_L0REQUESTTIME (0xFD070000) *LASER_WRITE_L0RETURNWINDOWSTART (0xFD080000) *LASER_WRITE_L0RETURNWINDOWSTOP (0xFD090000) *LASER_WRITE_QSWITCHEKSPLASTART (0xFD0A0000) *LASER_WRITE_QSWITCHEKSPLASTOP (0xFD0B0000) *LASER_WRITE_RUNMODE (0xFD0C0000) *LASER_WRITE_SAMPLECLOCKDIVIDER (0xFD0D0000) *LASER_WRITE_TRIGGERCONFIGURATION1 (0xFD0E0000) *LASER_WRITE_TRIGGERCONFIGURATION2 (0xFD0F0000) *LASER_WRITE_TTC_CONTROL (0xFD110000) *LASER_TOGGLE_TTC_RESET (0xFD120000) *LASER_WRITE_TTC_ROICONFIG1 (0xFD130000) *LASER_WRITE_TTC_ROICONFIG2 (0xFD140000) *LASER_TOGGLE_TTC_RESETCOUNTER (0xFD150000) *LASER_TOGGLE_TTC_ISSUETESTMODE (0xFD160000) *LASER_WRITE_TTC_L1LATENCY (0xFD170000) *LASER_WRITE_TTC_L2LATENCY (0xFD180000) *LASER_WRITE_TTC_ROILATENCY (0xFD190000) *LASER_WRITE_TTC_L1MSGLATENCY (0xFD1A0000) * LASER_SET_FLASHEKSPLASTARTTIME (0xFD1B0000 ) * LASER_SET_FLASHEKSPLAENDTIME (0xFD1C0000 ) * LASER_SET_SPECTRONSTARTTIME (0xFD1D0000 ) * LASER_SET_SPECTRONENDTIME (0xFD1E0000 ) * LASER_SET_SPECTRONDELAY (0xFD1F0000 ) * LASER_SET_L0REQUESTTIME (0xFD200000 ) * LASER_SET_L0RETURNWINDOWSTART (0xFD210000 ) * LASER_SET_L0RETURNWINDOWEND (0xFD220000 ) * LASER_SET_QSWITCHEKSPLASTART (0xFD230000 ) * LASER_SET_QSWITCHEKSPLAEND (0xFD240000 ) * LASER_CLEAR_COUNTERS (0xFD250000 ) ====Highlevel Commands==== *LASER_WRITE_MODEFREQVAL *LASER_WRITE_FLASHEKSPLASTARTTIME *LASER_WRITE_FLASHEKSPLAENDTIME LASER_WRITE_FLASHSPECTRONSTARTTIME *LASER_WRITE_FLASHSPECTRONENDTIME *LASER_WRITE_SPECTRONDELAY *LASER_WRITE_L0REQUESTTIME *LASER_WRITE_L0RETURNWINDOWSTART *LASER_WRITE_L0RETURNWINDOWSTOP *LASER_WRITE_QSWITCHEKSPLASTART *LASER_WRITE_QSWITCHEKSPLASTOP *LASER_WRITE_RUNMODE *LASER_WRITE_SAMPLECLOCKDIVIDER *LASER_WRITE_TRIGGERCONFIGURATION1 *LASER_WRITE_TRIGGERCONFIGURATION2 *LASER_WRITE_TTC_CONTROL *LASER_TOGGLE_TTC_RESET *LASER_WRITE_TTC_ROICONFIG1 *LASER_WRITE_TTC_ROICONFIG2 *LASER_TOGGLE_TTC_RESETCOUNTER *LASER_TOGGLE_TTC_ISSUETESTMODE *LASER_WRITE_TTC_L2LATENCY *LASER_WRITE_TTC_L1LATENCY *LASER_WRITE_TTC_ROILATENCY *LASER_WRITE_TTC_L1MSGLATENCY *LASER_SET_FLASHEKSPLASTARTTIME (Shuttertime, Flash Ekspla Time, Shift) *LASER_SET_FLASHEKSPLAENDTIME (Shuttertime, Flash Ekspla Time, Flash Ekspla duration, Shift) *LASER_SET_SPECTRONSTARTTIME (Shuttertime, Spectron Flash Time, Shift) *LASER_SET_SPECTRONENDTIME (Shuttertime, Spectron Flash Time, Spectron QSwitch Time, Shift) *LASER_SET_SPECTRONDELAY (Spectron QSwitch Veto Delay) *LASER_SET_L0REQUESTTIME (Shuttertime, L0Time, Shift) *LASER_SET_L0RETURNWINDOWSTART (Shuttertime, L0Time, L0 Window start, shift) *LASER_SET_L0RETURNWINDOWEND (Shuttertime, L0Time, L0 Window start, L0 Window end, shift) *LASER_SET_QSWITCHEKSPLASTART (Shuttertime, QSwitch Ekspla time, shift) *LASER_SET_QSWITCHEKSPLAEND (Shuttertime, QSwitch Ekspla time, QSwitch Ekspla duration, shift) *LASER_CLEAR_COUNTERS() ===States and Transitions=== Transitions: * LOAD_RECIPE * GO_STANDBY * GO_WARM_UP * GO_ON_FREE_RUN * GO_ON_TRIGGER * GO_STBY_CONFIGURED * GO_STBY_CONFIGURED States: *STANDBY *STBY_CONFIGURED *WARM_UP *ON_TRIGGER *ON_FREE_RUN ==TOR FeeServer== ===Services=== *TME *1DSFRL0 *1DSFRL1L *1DSFRL1M *1DSFRL1H *EDTORO *IDELAY *EDTRUIB0B1 *EDTRUIB2B3 *EDTRUIB4 *LVDSIGB0B1 *LVDSIGB2B3 *LVDSIGB4 ===Commands=== ====Highlevel Commands==== *TOR_WRITE_TME *TOR_WRITE_1DSFRL0 *TOR_WRITE_1DSFRL1L *TOR_WRITE_1DSFRL1M *TOR_WRITE_1DSFRL1H *TOR_WRITE_EDTORO *TOR_WRITE_IDELAY *TOR_WRITE_EDTRUIB0B1 *TOR_WRITE_EDTRUIB2B3 *TOR_WRITE_EDTRUIB4 ====Hex Commands==== *FEESVR_CMD_TOR (0x0e000000 | FEESERVER_CMD) *TOR_WRITE_TME (0x010000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL0 (0x020000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1L (0x030000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1M (0x040000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1H (0x050000 | FEESVR_CMD_BB) *TOR_WRITE_EDTORO (0x060000 | FEESVR_CMD_BB) *TOR_WRITE_IDELAY (0x070000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB0B1 (0x080000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB2B3 (0x090000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB4 (0x0a0000 | FEESVR_CMD_BB) ===States and Transitions=== ==Gating Pulser FeeServer== ===Services=== CONFREG FWVERSION PULSESTATUS PULSECOUNTER FSMSTREG ===Commands=== ====Highlevel Commands==== GPULSER_WRITE_CONFREG; GPULSER_TOGGLE_RESET; GPULSER_TOGGLE_GLOBAL_RESET; GPULSER_WRITE_TTC_CONTROL; GPULSER_TOGGLE_TTC_RESET; GPULSER_WRITE_TTC_ROICONFIG1; GPULSER_WRITE_TTC_ROICONFIG2; GPULSER_TOGGLE_TTC_RESETCOUNTER; GPULSER_TOGGLE_TTC_ISSUETESTMODE; GPULSER_WRITE_TTC_L2LATENCY; GPULSER_WRITE_TTC_L1LATENCY; GPULSER_WRITE_TTC_ROILATENCY; GPULSER_WRITE_TTC_L1MSGLATENCY; ====Hex Commands==== #define FEESVR_CMD_GPULSER (0x0f000000 | FEESERVER_CMD) #define GPULSER_WRITE_TTC_CONTROL (0x100000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_TTC_RESET (0x200000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_ROICONFIG1 (0x300000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_ROICONFIG2 (0x400000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_TTC_RESETCOUNTER (0x500000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_TTC_ISSUETESTMODE (0x600000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_L1LATENCY (0x700000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_L2LATENCY (0x800000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_ROILATENCY (0x900000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_TTC_L1MSGLATENCY (0xA00000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_RESET (0xB00000 | FEESVR_CMD_GPULSER) #define GPULSER_TOGGLE_GLOBAL_RESET (0xC00000 | FEESVR_CMD_GPULSER) #define GPULSER_WRITE_CONFREG (0xD00000 | FEESVR_CMD_GPULSER) ===States and Transitions=== ==RCU FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== 57e285b92ec93dccf59c113642c7254b8801df4e 617 616 2009-07-07T11:39:49Z Dfe002 7 wikitext text/x-wiki ==Busybox FeeServer== ===Services=== *TXR *RXMP *EIDFIFOC *CEID0 *CEID1 *CEID2 *MREID0 *MREID1 *MREID2 *L0TTO *FEEBA *FSMH *RRTO *CRID *RC *BT0 *BT1 *RXMF *TMC0 *TMC1 *L0L *BCIDO *L1C *L2AC *L2RC ===Commands=== ====Hex Commands==== *FEESVR_CMD_BB (0x0c000000 | FEESERVER_CMD) *BB_INIT (0x010000 | FEESVR_CMD_BB) *INIT_BUSY_BOX (0x010000 | FEESVR_CMD_BB) //Depricated *BB_WRITE_STATUS (0x020000 | FEESVR_CMD_BB) *BB_WRITE_RXMF (0x030000 | FEESVR_CMD_BB) *BB_WRITE_RRTO (0x040000 | FEESVR_CMD_BB) *BB_WRITE_FM (0x050000 | FEESVR_CMD_BB) *BB_WRITE_FSMH (0x060000 | FEESVR_CMD_BB) *BB_WRITE_FEEBA (0x070000 | FEESVR_CMD_BB) *BB_WRITE_L0TTO (0x080000 | FEESVR_CMD_BB) *BB_WRITE_L0_TIMEOUT (0x080000 | FEESVR_CMD_BB) //Depricated *BB_WRITE_TX (0x090000 | FEESVR_CMD_BB) *BB_WRITE_TMC0 (0x0a0000 | FEESVR_CMD_BB) *BB_WRITE_TMC1 (0x0b0000 | FEESVR_CMD_BB) *BB_WRITE_TMR (0x0c0000 | FEESVR_CMD_BB) *BB_WRITE_L0L (0x0d0000 | FEESVR_CMD_BB) *BB_WRITE_BCIDO (0x0e0000 | FEESVR_CMD_BB) *BB_FIRMWARE_RESET (0x0f0000 | FEESVR_CMD_BB) ====Highlevel Commands==== *BB_WRITE_TX *BB_WRITE_L0TTO *BB_WRITE_FEEBA *BB_WRITE_FSMH *BB_WRITE_FM *BB_WRITE_RRTO *BB_WRITE_RXMF ===States and Transitions=== ==Laser Sync FeeServer== ===Services=== *MODEFREQVAL *FLASHEKSPLASTARTTIME *FLASHEKSPLAENDTIME *FLASHSPECTRONSTARTTIME *FLASHSPECTRONENDTIME *SPECTRONDELAY *L0REQUESTTIME *L0RETURNWINDOWSTART *L0RETURNWINDOWSTOP *QSWITCHEKSPLASTART *QSWITCHEKSPLASTOP *RUNMODE *SAMPLECLOCKDIVIDER *TRIGGERCONFIGURATION1 *TRIGGERCONFIGURATION2 *RCUVERSION *CTPSIGNATURE *SHUTTERCOUNTER *EKSPLAFLASHCOUNTER *SPECTRONFLASHCOUNTER *EKSPLAQSWITCHCOUNTER *SPECTRONQSWITCHCOUNTER *L0REQUESTCOUNTER *L0RECEIVEDCOUNTER *L0RECEIVEDINWINDOWCOUNTER *L0TIMEOUTCOUNTER *L0RETURNTIMER *ACTUALLASERRATE *CYCLETIMER *TTC_CONTROL *TTC_ROICONFIG1 *TTC_ROICONFIG2 *TTC_L1LATENCY *TTC_L2LATENCY *TTC_ROILATENCY *TTC_L1MSGLATENCY *TTC_PREPULSECNT *TTC_BCIDLOCAL *TTC_L0COUNTER *TTC_L1MSGCOUNTER *TTC_L2ACOUNTER *TTC_L2RCOUNTER *TTC_ROICOUNTER *TTC_HAMMINGERRCNT *TTC_ERRORCNT *TTC_BUFFEREDEVENTS *TTC_DAQHEADER1 *TTC_DAQHEADER2 *TTC_DAQHEADER3 *TTC_DAQHEADER4 *TTC_DAQHEADER5 *TTC_DAQHEADER6 *TTC_DAQHEADER7 *TTC_EVENTINFO ===Commands=== ====Hex Commands==== *LASER_WRITE_MODEFREQVAL (0xFD010000) *LASER_WRITE_FLASHEKSPLASTARTTIME (0xFD020000) *LASER_WRITE_FLASHEKSPLAENDTIME (0xFD030000) *LASER_WRITE_FLASHSPECTRONSTARTTIME (0xFD040000) *LASER_WRITE_FLASHSPECTRONENDTIME (0xFD050000) *LASER_WRITE_SPECTRONDELAY (0xFD060000) *LASER_WRITE_L0REQUESTTIME (0xFD070000) *LASER_WRITE_L0RETURNWINDOWSTART (0xFD080000) *LASER_WRITE_L0RETURNWINDOWSTOP (0xFD090000) *LASER_WRITE_QSWITCHEKSPLASTART (0xFD0A0000) *LASER_WRITE_QSWITCHEKSPLASTOP (0xFD0B0000) *LASER_WRITE_RUNMODE (0xFD0C0000) *LASER_WRITE_SAMPLECLOCKDIVIDER (0xFD0D0000) *LASER_WRITE_TRIGGERCONFIGURATION1 (0xFD0E0000) *LASER_WRITE_TRIGGERCONFIGURATION2 (0xFD0F0000) *LASER_WRITE_TTC_CONTROL (0xFD110000) *LASER_TOGGLE_TTC_RESET (0xFD120000) *LASER_WRITE_TTC_ROICONFIG1 (0xFD130000) *LASER_WRITE_TTC_ROICONFIG2 (0xFD140000) *LASER_TOGGLE_TTC_RESETCOUNTER (0xFD150000) *LASER_TOGGLE_TTC_ISSUETESTMODE (0xFD160000) *LASER_WRITE_TTC_L1LATENCY (0xFD170000) *LASER_WRITE_TTC_L2LATENCY (0xFD180000) *LASER_WRITE_TTC_ROILATENCY (0xFD190000) *LASER_WRITE_TTC_L1MSGLATENCY (0xFD1A0000) * LASER_SET_FLASHEKSPLASTARTTIME (0xFD1B0000 ) * LASER_SET_FLASHEKSPLAENDTIME (0xFD1C0000 ) * LASER_SET_SPECTRONSTARTTIME (0xFD1D0000 ) * LASER_SET_SPECTRONENDTIME (0xFD1E0000 ) * LASER_SET_SPECTRONDELAY (0xFD1F0000 ) * LASER_SET_L0REQUESTTIME (0xFD200000 ) * LASER_SET_L0RETURNWINDOWSTART (0xFD210000 ) * LASER_SET_L0RETURNWINDOWEND (0xFD220000 ) * LASER_SET_QSWITCHEKSPLASTART (0xFD230000 ) * LASER_SET_QSWITCHEKSPLAEND (0xFD240000 ) * LASER_CLEAR_COUNTERS (0xFD250000 ) ====Highlevel Commands==== *LASER_WRITE_MODEFREQVAL *LASER_WRITE_FLASHEKSPLASTARTTIME *LASER_WRITE_FLASHEKSPLAENDTIME LASER_WRITE_FLASHSPECTRONSTARTTIME *LASER_WRITE_FLASHSPECTRONENDTIME *LASER_WRITE_SPECTRONDELAY *LASER_WRITE_L0REQUESTTIME *LASER_WRITE_L0RETURNWINDOWSTART *LASER_WRITE_L0RETURNWINDOWSTOP *LASER_WRITE_QSWITCHEKSPLASTART *LASER_WRITE_QSWITCHEKSPLASTOP *LASER_WRITE_RUNMODE *LASER_WRITE_SAMPLECLOCKDIVIDER *LASER_WRITE_TRIGGERCONFIGURATION1 *LASER_WRITE_TRIGGERCONFIGURATION2 *LASER_WRITE_TTC_CONTROL *LASER_TOGGLE_TTC_RESET *LASER_WRITE_TTC_ROICONFIG1 *LASER_WRITE_TTC_ROICONFIG2 *LASER_TOGGLE_TTC_RESETCOUNTER *LASER_TOGGLE_TTC_ISSUETESTMODE *LASER_WRITE_TTC_L2LATENCY *LASER_WRITE_TTC_L1LATENCY *LASER_WRITE_TTC_ROILATENCY *LASER_WRITE_TTC_L1MSGLATENCY *LASER_SET_FLASHEKSPLASTARTTIME (Shuttertime, Flash Ekspla Time, Shift) *LASER_SET_FLASHEKSPLAENDTIME (Shuttertime, Flash Ekspla Time, Flash Ekspla duration, Shift) *LASER_SET_SPECTRONSTARTTIME (Shuttertime, Spectron Flash Time, Shift) *LASER_SET_SPECTRONENDTIME (Shuttertime, Spectron Flash Time, Spectron QSwitch Time, Shift) *LASER_SET_SPECTRONDELAY (Spectron QSwitch Veto Delay) *LASER_SET_L0REQUESTTIME (Shuttertime, L0Time, Shift) *LASER_SET_L0RETURNWINDOWSTART (Shuttertime, L0Time, L0 Window start, shift) *LASER_SET_L0RETURNWINDOWEND (Shuttertime, L0Time, L0 Window start, L0 Window end, shift) *LASER_SET_QSWITCHEKSPLASTART (Shuttertime, QSwitch Ekspla time, shift) *LASER_SET_QSWITCHEKSPLAEND (Shuttertime, QSwitch Ekspla time, QSwitch Ekspla duration, shift) *LASER_CLEAR_COUNTERS() ===States and Transitions=== Transitions: * LOAD_RECIPE * GO_STANDBY * GO_WARM_UP * GO_ON_FREE_RUN * GO_ON_TRIGGER * GO_STBY_CONFIGURED * GO_STBY_CONFIGURED States: *STANDBY *STBY_CONFIGURED *WARM_UP *ON_TRIGGER *ON_FREE_RUN ==TOR FeeServer== ===Services=== *TME *1DSFRL0 *1DSFRL1L *1DSFRL1M *1DSFRL1H *EDTORO *IDELAY *EDTRUIB0B1 *EDTRUIB2B3 *EDTRUIB4 *LVDSIGB0B1 *LVDSIGB2B3 *LVDSIGB4 ===Commands=== ====Highlevel Commands==== *TOR_WRITE_TME *TOR_WRITE_1DSFRL0 *TOR_WRITE_1DSFRL1L *TOR_WRITE_1DSFRL1M *TOR_WRITE_1DSFRL1H *TOR_WRITE_EDTORO *TOR_WRITE_IDELAY *TOR_WRITE_EDTRUIB0B1 *TOR_WRITE_EDTRUIB2B3 *TOR_WRITE_EDTRUIB4 ====Hex Commands==== *FEESVR_CMD_TOR (0x0e000000 | FEESERVER_CMD) *TOR_WRITE_TME (0x010000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL0 (0x020000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1L (0x030000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1M (0x040000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1H (0x050000 | FEESVR_CMD_BB) *TOR_WRITE_EDTORO (0x060000 | FEESVR_CMD_BB) *TOR_WRITE_IDELAY (0x070000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB0B1 (0x080000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB2B3 (0x090000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB4 (0x0a0000 | FEESVR_CMD_BB) ===States and Transitions=== ==Gating Pulser FeeServer== ===Services=== *CONFREG *FWVERSION *PULSESTATUS *PULSECOUNTER *FSMSTREG ===Commands=== ====Highlevel Commands==== *GPULSER_WRITE_CONFREG; *GPULSER_TOGGLE_RESET; *GPULSER_TOGGLE_GLOBAL_RESET; *GPULSER_WRITE_TTC_CONTROL; *GPULSER_TOGGLE_TTC_RESET; *GPULSER_WRITE_TTC_ROICONFIG1; *GPULSER_WRITE_TTC_ROICONFIG2; *GPULSER_TOGGLE_TTC_RESETCOUNTER; *GPULSER_TOGGLE_TTC_ISSUETESTMODE; *GPULSER_WRITE_TTC_L2LATENCY; *GPULSER_WRITE_TTC_L1LATENCY; *GPULSER_WRITE_TTC_ROILATENCY; *GPULSER_WRITE_TTC_L1MSGLATENCY; ====Hex Commands==== *FEESVR_CMD_GPULSER (0x0f000000 | FEESERVER_CMD) *GPULSER_WRITE_TTC_CONTROL (0x100000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_TTC_RESET (0x200000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_ROICONFIG1 (0x300000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_ROICONFIG2 (0x400000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_TTC_RESETCOUNTER (0x500000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_TTC_ISSUETESTMODE (0x600000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_L1LATENCY (0x700000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_L2LATENCY (0x800000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_ROILATENCY (0x900000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_L1MSGLATENCY (0xA00000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_RESET (0xB00000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_GLOBAL_RESET (0xC00000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_CONFREG (0xD00000 | FEESVR_CMD_GPULSER) ===States and Transitions=== ==RCU FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== 3f971597123719a94367907d090027b69c987d32 618 617 2009-07-07T11:45:40Z Dfe002 7 wikitext text/x-wiki ==Busybox FeeServer== ===Services=== *TXR *RXMP *EIDFIFOC *CEID0 *CEID1 *CEID2 *MREID0 *MREID1 *MREID2 *L0TTO *FEEBA *FSMH *RRTO *CRID *RC *BT0 *BT1 *RXMF *TMC0 *TMC1 *L0L *BCIDO *L1C *L2AC *L2RC ===Commands=== ====Hex Commands==== *FEESVR_CMD_BB (0x0c000000 | FEESERVER_CMD) *BB_INIT (0x010000 | FEESVR_CMD_BB) *INIT_BUSY_BOX (0x010000 | FEESVR_CMD_BB) //Depricated *BB_WRITE_STATUS (0x020000 | FEESVR_CMD_BB) *BB_WRITE_RXMF (0x030000 | FEESVR_CMD_BB) *BB_WRITE_RRTO (0x040000 | FEESVR_CMD_BB) *BB_WRITE_FM (0x050000 | FEESVR_CMD_BB) *BB_WRITE_FSMH (0x060000 | FEESVR_CMD_BB) *BB_WRITE_FEEBA (0x070000 | FEESVR_CMD_BB) *BB_WRITE_L0TTO (0x080000 | FEESVR_CMD_BB) *BB_WRITE_L0_TIMEOUT (0x080000 | FEESVR_CMD_BB) //Depricated *BB_WRITE_TX (0x090000 | FEESVR_CMD_BB) *BB_WRITE_TMC0 (0x0a0000 | FEESVR_CMD_BB) *BB_WRITE_TMC1 (0x0b0000 | FEESVR_CMD_BB) *BB_WRITE_TMR (0x0c0000 | FEESVR_CMD_BB) *BB_WRITE_L0L (0x0d0000 | FEESVR_CMD_BB) *BB_WRITE_BCIDO (0x0e0000 | FEESVR_CMD_BB) *BB_FIRMWARE_RESET (0x0f0000 | FEESVR_CMD_BB) ====Highlevel Commands==== *BB_WRITE_TX *BB_WRITE_L0TTO *BB_WRITE_FEEBA *BB_WRITE_FSMH *BB_WRITE_FM *BB_WRITE_RRTO *BB_WRITE_RXMF ===States and Transitions=== ==Laser Sync FeeServer== ===Services=== *MODEFREQVAL *FLASHEKSPLASTARTTIME *FLASHEKSPLAENDTIME *FLASHSPECTRONSTARTTIME *FLASHSPECTRONENDTIME *SPECTRONDELAY *L0REQUESTTIME *L0RETURNWINDOWSTART *L0RETURNWINDOWSTOP *QSWITCHEKSPLASTART *QSWITCHEKSPLASTOP *RUNMODE *SAMPLECLOCKDIVIDER *TRIGGERCONFIGURATION1 *TRIGGERCONFIGURATION2 *RCUVERSION *CTPSIGNATURE *SHUTTERCOUNTER *EKSPLAFLASHCOUNTER *SPECTRONFLASHCOUNTER *EKSPLAQSWITCHCOUNTER *SPECTRONQSWITCHCOUNTER *L0REQUESTCOUNTER *L0RECEIVEDCOUNTER *L0RECEIVEDINWINDOWCOUNTER *L0TIMEOUTCOUNTER *L0RETURNTIMER *ACTUALLASERRATE *CYCLETIMER *TTC_CONTROL *TTC_ROICONFIG1 *TTC_ROICONFIG2 *TTC_L1LATENCY *TTC_L2LATENCY *TTC_ROILATENCY *TTC_L1MSGLATENCY *TTC_PREPULSECNT *TTC_BCIDLOCAL *TTC_L0COUNTER *TTC_L1MSGCOUNTER *TTC_L2ACOUNTER *TTC_L2RCOUNTER *TTC_ROICOUNTER *TTC_HAMMINGERRCNT *TTC_ERRORCNT *TTC_BUFFEREDEVENTS *TTC_DAQHEADER1 *TTC_DAQHEADER2 *TTC_DAQHEADER3 *TTC_DAQHEADER4 *TTC_DAQHEADER5 *TTC_DAQHEADER6 *TTC_DAQHEADER7 *TTC_EVENTINFO ===Commands=== ====Hex Commands==== *LASER_WRITE_MODEFREQVAL (0xFD010000) *LASER_WRITE_FLASHEKSPLASTARTTIME (0xFD020000) *LASER_WRITE_FLASHEKSPLAENDTIME (0xFD030000) *LASER_WRITE_FLASHSPECTRONSTARTTIME (0xFD040000) *LASER_WRITE_FLASHSPECTRONENDTIME (0xFD050000) *LASER_WRITE_SPECTRONDELAY (0xFD060000) *LASER_WRITE_L0REQUESTTIME (0xFD070000) *LASER_WRITE_L0RETURNWINDOWSTART (0xFD080000) *LASER_WRITE_L0RETURNWINDOWSTOP (0xFD090000) *LASER_WRITE_QSWITCHEKSPLASTART (0xFD0A0000) *LASER_WRITE_QSWITCHEKSPLASTOP (0xFD0B0000) *LASER_WRITE_RUNMODE (0xFD0C0000) *LASER_WRITE_SAMPLECLOCKDIVIDER (0xFD0D0000) *LASER_WRITE_TRIGGERCONFIGURATION1 (0xFD0E0000) *LASER_WRITE_TRIGGERCONFIGURATION2 (0xFD0F0000) *LASER_WRITE_TTC_CONTROL (0xFD110000) *LASER_TOGGLE_TTC_RESET (0xFD120000) *LASER_WRITE_TTC_ROICONFIG1 (0xFD130000) *LASER_WRITE_TTC_ROICONFIG2 (0xFD140000) *LASER_TOGGLE_TTC_RESETCOUNTER (0xFD150000) *LASER_TOGGLE_TTC_ISSUETESTMODE (0xFD160000) *LASER_WRITE_TTC_L1LATENCY (0xFD170000) *LASER_WRITE_TTC_L2LATENCY (0xFD180000) *LASER_WRITE_TTC_ROILATENCY (0xFD190000) *LASER_WRITE_TTC_L1MSGLATENCY (0xFD1A0000) * LASER_SET_FLASHEKSPLASTARTTIME (0xFD1B0000 ) * LASER_SET_FLASHEKSPLAENDTIME (0xFD1C0000 ) * LASER_SET_SPECTRONSTARTTIME (0xFD1D0000 ) * LASER_SET_SPECTRONENDTIME (0xFD1E0000 ) * LASER_SET_SPECTRONDELAY (0xFD1F0000 ) * LASER_SET_L0REQUESTTIME (0xFD200000 ) * LASER_SET_L0RETURNWINDOWSTART (0xFD210000 ) * LASER_SET_L0RETURNWINDOWEND (0xFD220000 ) * LASER_SET_QSWITCHEKSPLASTART (0xFD230000 ) * LASER_SET_QSWITCHEKSPLAEND (0xFD240000 ) * LASER_CLEAR_COUNTERS (0xFD250000 ) ====Highlevel Commands==== *LASER_WRITE_MODEFREQVAL *LASER_WRITE_FLASHEKSPLASTARTTIME *LASER_WRITE_FLASHEKSPLAENDTIME LASER_WRITE_FLASHSPECTRONSTARTTIME *LASER_WRITE_FLASHSPECTRONENDTIME *LASER_WRITE_SPECTRONDELAY *LASER_WRITE_L0REQUESTTIME *LASER_WRITE_L0RETURNWINDOWSTART *LASER_WRITE_L0RETURNWINDOWSTOP *LASER_WRITE_QSWITCHEKSPLASTART *LASER_WRITE_QSWITCHEKSPLASTOP *LASER_WRITE_RUNMODE *LASER_WRITE_SAMPLECLOCKDIVIDER *LASER_WRITE_TRIGGERCONFIGURATION1 *LASER_WRITE_TRIGGERCONFIGURATION2 *LASER_WRITE_TTC_CONTROL *LASER_TOGGLE_TTC_RESET *LASER_WRITE_TTC_ROICONFIG1 *LASER_WRITE_TTC_ROICONFIG2 *LASER_TOGGLE_TTC_RESETCOUNTER *LASER_TOGGLE_TTC_ISSUETESTMODE *LASER_WRITE_TTC_L2LATENCY *LASER_WRITE_TTC_L1LATENCY *LASER_WRITE_TTC_ROILATENCY *LASER_WRITE_TTC_L1MSGLATENCY *LASER_SET_FLASHEKSPLASTARTTIME (Shuttertime, Flash Ekspla Time, Shift) *LASER_SET_FLASHEKSPLAENDTIME (Shuttertime, Flash Ekspla Time, Flash Ekspla duration, Shift) *LASER_SET_SPECTRONSTARTTIME (Shuttertime, Spectron Flash Time, Shift) *LASER_SET_SPECTRONENDTIME (Shuttertime, Spectron Flash Time, Spectron QSwitch Time, Shift) *LASER_SET_SPECTRONDELAY (Spectron QSwitch Veto Delay) *LASER_SET_L0REQUESTTIME (Shuttertime, L0Time, Shift) *LASER_SET_L0RETURNWINDOWSTART (Shuttertime, L0Time, L0 Window start, shift) *LASER_SET_L0RETURNWINDOWEND (Shuttertime, L0Time, L0 Window start, L0 Window end, shift) *LASER_SET_QSWITCHEKSPLASTART (Shuttertime, QSwitch Ekspla time, shift) *LASER_SET_QSWITCHEKSPLAEND (Shuttertime, QSwitch Ekspla time, QSwitch Ekspla duration, shift) *LASER_CLEAR_COUNTERS() ===States and Transitions=== Transitions: * LOAD_RECIPE * GO_STANDBY * GO_WARM_UP * GO_ON_FREE_RUN * GO_ON_TRIGGER * GO_STBY_CONFIGURED * GO_STBY_CONFIGURED States: *STANDBY *STBY_CONFIGURED *WARM_UP *ON_TRIGGER *ON_FREE_RUN ==TOR FeeServer== ===Services=== *TME *1DSFRL0 *1DSFRL1L *1DSFRL1M *1DSFRL1H *EDTORO *IDELAY *EDTRUIB0B1 *EDTRUIB2B3 *EDTRUIB4 *LVDSIGB0B1 *LVDSIGB2B3 *LVDSIGB4 ===Commands=== ====Highlevel Commands==== *TOR_WRITE_TME *TOR_WRITE_1DSFRL0 *TOR_WRITE_1DSFRL1L *TOR_WRITE_1DSFRL1M *TOR_WRITE_1DSFRL1H *TOR_WRITE_EDTORO *TOR_WRITE_IDELAY *TOR_WRITE_EDTRUIB0B1 *TOR_WRITE_EDTRUIB2B3 *TOR_WRITE_EDTRUIB4 ====Hex Commands==== *FEESVR_CMD_TOR (0x0e000000 | FEESERVER_CMD) *TOR_WRITE_TME (0x010000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL0 (0x020000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1L (0x030000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1M (0x040000 | FEESVR_CMD_BB) *TOR_WRITE_1DSFRL1H (0x050000 | FEESVR_CMD_BB) *TOR_WRITE_EDTORO (0x060000 | FEESVR_CMD_BB) *TOR_WRITE_IDELAY (0x070000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB0B1 (0x080000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB2B3 (0x090000 | FEESVR_CMD_BB) *TOR_WRITE_EDTRUIB4 (0x0a0000 | FEESVR_CMD_BB) ===States and Transitions=== ==Gating Pulser FeeServer== ===Services=== *CONFREG *FWVERSION *PULSESTATUS *PULSECOUNTER *FSMSTREG ===Commands=== ====Highlevel Commands==== *GPULSER_WRITE_CONFREG; *GPULSER_TOGGLE_RESET; *GPULSER_TOGGLE_GLOBAL_RESET; *GPULSER_WRITE_TTC_CONTROL; *GPULSER_TOGGLE_TTC_RESET; *GPULSER_WRITE_TTC_ROICONFIG1; *GPULSER_WRITE_TTC_ROICONFIG2; *GPULSER_TOGGLE_TTC_RESETCOUNTER; *GPULSER_TOGGLE_TTC_ISSUETESTMODE; *GPULSER_WRITE_TTC_L2LATENCY; *GPULSER_WRITE_TTC_L1LATENCY; *GPULSER_WRITE_TTC_ROILATENCY; *GPULSER_WRITE_TTC_L1MSGLATENCY; ====Hex Commands==== *FEESVR_CMD_GPULSER (0x0f000000 | FEESERVER_CMD) *GPULSER_WRITE_TTC_CONTROL (0x100000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_TTC_RESET (0x200000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_ROICONFIG1 (0x300000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_ROICONFIG2 (0x400000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_TTC_RESETCOUNTER (0x500000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_TTC_ISSUETESTMODE (0x600000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_L1LATENCY (0x700000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_L2LATENCY (0x800000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_ROILATENCY (0x900000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_TTC_L1MSGLATENCY (0xA00000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_RESET (0xB00000 | FEESVR_CMD_GPULSER) *GPULSER_TOGGLE_GLOBAL_RESET (0xC00000 | FEESVR_CMD_GPULSER) *GPULSER_WRITE_CONFREG (0xD00000 | FEESVR_CMD_GPULSER) ===States and Transitions=== ==RCU FeeServer== ===Services=== ===Commands=== ====Highlevel Commands==== ===States and Transitions=== [[User:Dfe002|Dominik]] 11:45, 7 July 2009 (UTC) dac06cdcc54e00e763e81f34e57c0df74ea76c7c 6 195 619 2009-07-08T16:00:46Z Ato061 22 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 196 630 2009-08-19T11:41:48Z Dfe002 7 Created page with 'Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find ...' wikitext text/x-wiki Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find money for it. ==XYZ-table setup== * 1µm fiber to scan the detectors. * optical gating grid to calibrate the XYZ-table. [[User:Dfe002|Dominik]] 11:41, 19 August 2009 (UTC) 0f12b3bbdda0088e8e6f7f13cf72405924339423 0 197 636 2009-08-21T07:50:54Z Dfe002 7 Created page with 'Some material for presentations should go here. Plots can be discussed during next meeting.' wikitext text/x-wiki Some material for presentations should go here. Plots can be discussed during next meeting. 8503982c8bb090370f08cfdbcf3e8790bb538505 2 198 637 2009-08-21T09:01:10Z Dfe002 7 Created page with 'Camilla' wikitext text/x-wiki Camilla 695e26ac527003167ec0fda478dc3a7283b7e10b 639 637 2009-08-21T10:49:55Z Dfe002 7 wikitext text/x-wiki Camilla Hanquist Stokkevåg f02f8358857e33cf362b006217125f5cf066604c 2 199 638 2009-08-21T10:49:09Z Dfe002 7 Created page with 'Matthias Rudolph Richter' wikitext text/x-wiki Matthias Rudolph Richter 376dcf8ba011dc83091158e492fa86c7102c2057 0 2 641 18 2009-08-24T07:24:58Z Dfe002 7 wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[PHOS PVSS panels]] * [[PHOS TOR documentation]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Tips & Tricks corner]] <center>[[Image:alice.gif]]</center> 96d4ac97a6a8aaecbdddbd61d67c83c6210bd6b4 643 641 2009-08-24T07:31:57Z Dfe002 7 wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[PHOS PVSS panels]] * [[PHOS TOR]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Tips & Tricks corner]] <center>[[Image:alice.gif]]</center> 57d8929c84e7fe7e9faefe09a216af87710d3e93 0 201 644 2009-08-24T07:36:15Z Dfe002 7 Created page with '= TOR Documentation = * TOR overview * Firmware Version history ** Version 1.0 ** Version 1.1 * Download section ** Version 1.0 ** Version 1.1 ** Documentation = TOR FeeSer...' wikitext text/x-wiki = TOR Documentation = * TOR overview * Firmware Version history ** Version 1.0 ** Version 1.1 * Download section ** Version 1.0 ** Version 1.1 ** Documentation = TOR FeeServer = see here: https://wikihost.uib.no/ift/index.php/Documentation_of_different_FeeServer_Control_Engines#TOR_FeeServer 32669d0752a18133be5aef20043442bc02897df7 645 644 2009-08-24T07:37:13Z Dfe002 7 wikitext text/x-wiki = TOR Documentation = * TOR overview * Firmware Version history ** Version 1.0 ** Version 1.1 * Download section ** Version 1.0 ** Version 1.1 ** Documentation = TOR FeeServer = see here: https://wikihost.uib.no/ift/index.php/Documentation_of_different_FeeServer_Control_Engines#TOR_FeeServer [[User:Dfe002|Dominik]] 07:37, 24 August 2009 (UTC) ae87b80af76ffcff439144cf3f41493c46990eec 0 202 647 2009-08-24T09:07:22Z Nfyku 4 Created page with '== Nettressurser for bruk i PHYS222 == === Halvlederfysikk === [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Kretssimulering ...' wikitext text/x-wiki == Nettressurser for bruk i PHYS222 == === Halvlederfysikk === [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] 8c9d0c25f2d1dd258c76fe678677c296be488043 648 647 2009-08-24T09:10:33Z Nfyku 4 wikitext text/x-wiki == Nettressurser for bruk i PHYS222 == === Halvlederfysikk === [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] == Prosessteknologi == [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] a418611c6838e4e105f8b2d91318bddccef033b7 654 648 2009-08-24T12:06:49Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == == Fagbøker == * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] == Prosessteknologi == [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] 759b8957e67e6deb414d685f84a632e5e46aa0f8 655 654 2009-08-24T12:07:15Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == == Fagbøker == * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] fe6bd3a842dc07c15f49e3d67ef440650f9a6a20 656 655 2009-08-24T12:07:41Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] b660eca4cdb4e031258c1808e935c2d0d9271e24 670 656 2009-08-25T09:09:00Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] 8705e0b820acead86e0e5975068313bf7fd09711 0 2 649 643 2009-08-24T09:26:58Z Dfe002 7 wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[PHOS PVSS panels]] * [[PHOS TOR]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Tips & Tricks corner]] * [[Coming to CERN]] <center>[[Image:alice.gif]]</center> f00a0ade17db33dff85a9182cbb7ddd64152e4f3 0 203 650 2009-08-24T09:53:17Z Dfe002 7 Created page with 'Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled C...' wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 == To do shifts == * You need a security course, go to the Registration Service, building 55 (http://building.web.cern.ch/map/building?bno=55) * Request access for the counting room in edh: https://edh.cern.ch --> Access Request. The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * Book your shifts as: https://alicesms.cern.ch/ [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) f9c7c196553ffa9f980e9d250e24dc3c34c7f732 651 650 2009-08-24T09:56:48Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 * You need a paper that states your affiliation with the University in english, or a student card. == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 == To do shifts == * You need a security course, go to the Registration Service, building 55 (http://building.web.cern.ch/map/building?bno=55) * Request access for the counting room in edh: https://edh.cern.ch --> Access Request. The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * Book your shifts as: https://alicesms.cern.ch/ [[User:Dfe002|Dominik]] 09:56, 24 August 2009 (UTC) 8537ed4793cefb004779cae8eb2aa24cfd905f52 652 651 2009-08-24T11:47:54Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 == To do shifts == * You need a security course, go to the Registration Service, building 55 (http://building.web.cern.ch/map/building?bno=55) * Request access for the counting room in edh: https://edh.cern.ch --> Access Request. The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * Book your shifts as: https://alicesms.cern.ch/ [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) f9c7c196553ffa9f980e9d250e24dc3c34c7f732 668 652 2009-08-25T08:47:40Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 == To do shifts == * You need a security course, go to the Registration Service, building 55 (http://building.web.cern.ch/map/building?bno=55) * Request access for the counting room in edh: https://edh.cern.ch --> Access Request. The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) f2802305a21aa34bc4c2ebde2523a82f3f6a8b28 669 668 2009-08-25T08:56:43Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 == To do shifts == * You need a security course, go to the Registration Service, building 55 (http://building.web.cern.ch/map/building?bno=55) * Request access for the counting room in edh: https://edh.cern.ch --> Access Request. The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) f3b514c49ff2c860deb068faf180275fae45f2a0 688 669 2009-09-01T09:54:07Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 * If you want to use the Bergen car, you need a CERN drivings license. Bring your drivings licence and go to the ALICE secreteriat. They will scan this in and request it for you. To get the CERN driving license, you need security course level 1+2, see below. == To do shifts == * You need a security course, this you can do online: (http://sir.cern.ch) * Request access for the control room in edh: https://edh.cern.ch --> Access Request. NB: You need a special EDH-password to request, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) ff28a9a9bd4b1e341f9ef5100dc299b65f762429 689 688 2009-09-01T11:40:08Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html. If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. -St.Genis- (Lies between CERN and ALICE) * http://balladins.eu/fiche_hotel.php?id=166 * http://www.hotel-sofia.com/ -Between CERN and Geneve- * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 * If you want to use the Bergen car, you need a CERN drivings license. Bring your drivings licence and go to the ALICE secreteriat. They will scan this in and request it for you. To get the CERN driving license, you need security course level 1+2, see below. == To do shifts == * You need a security course, this you can do online: (http://sir.cern.ch) * Request access for the control room in edh: https://edh.cern.ch --> Access Request. NB: You need a special EDH-password to be able to request, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) d78feca979868b343cfa017b74747430523832ff 690 689 2009-09-01T11:47:29Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html. If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. -St.Genis- (Lies between CERN and ALICE) * http://balladins.eu/fiche_hotel.php?id=166 * http://www.hotel-sofia.com/ -Between CERN and Geneve- * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 * If you want to use the Bergen car, you need a CERN drivings license. Bring your drivings licence and go to the ALICE secreteriat. They will scan this in and request it for you. To get the CERN driving license, you need security course level 1+2, see below. == To do shifts == * You need a security course, this you can do online: (http://sir.cern.ch) * Request access for the control room in edh: https://edh.cern.ch --> Access Request. NB: You need a special EDH-password to be able to request, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * HLT shiftguide: https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) 51bab57d750f65abc5b64b7ec3e7832e2cb5fd24 692 690 2009-09-01T12:20:03Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == * Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html. If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. -St.Genis- (Lies between CERN and ALICE) * http://balladins.eu/fiche_hotel.php?id=166 * http://www.hotel-sofia.com/ -Between CERN and Geneve- * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 * If you want to use the Bergen car, you need a CERN drivings license. Bring your drivings licence and go to the ALICE secreteriat. They will scan this in and request it for you. To get the CERN driving license, you need security course level 1+2, see below. == To do shifts == * You need a security course, this you can do online: (http://sir.cern.ch). * Request access for the control room in edh: https://edh.cern.ch --> Access Request. NB: You need a special EDH-password to be able to request, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * HLT shiftguide: https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 09:53, 24 August 2009 (UTC) 5fd64c92eca7c4e06dbfed19acdfa29ebf21e390 693 692 2009-09-01T12:44:14Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == -Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html. If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. *Hint: If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended - as above. -St.Genis- (Lies between CERN and ALICE) * http://balladins.eu/fiche_hotel.php?id=166 * http://www.hotel-sofia.com/ -Between CERN and Geneve- * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 * If you want to use the Bergen car, you need a CERN drivings license. Bring your drivings licence and go to the ALICE secreteriat. They will scan this in and request it for you. To get the CERN driving license, you need security course level 1+2, see below. == To do shifts == * You need a security course, this you can do online: (http://sir.cern.ch). * Request access for the control room in edh: https://edh.cern.ch --> Access Request. NB: You need a special EDH-password to be able to request, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * HLT shiftguide: https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 1 September 2009 (UTC) 3e705cf7053024f2dfaff0d9152232b09010413b 697 693 2009-09-01T13:36:27Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == -Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html. If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. *Hint: If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended - as above. -St.Genis- (Lies between CERN and ALICE) * http://balladins.eu/fiche_hotel.php?id=166 * http://www.hotel-sofia.com/ -Between CERN and Geneve- * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 * If you want to use the Bergen car, you need a CERN drivings license. Bring your drivings licence and go to the ALICE secreteriat. They will scan this in and request it for you. To get the CERN driving license, you need security course level 1+2, see below. == To do shifts == * You need a security course, this you can do online: (http://sir.cern.ch). * Request access for the control room in edh: https://edh.cern.ch --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * HLT shiftguide: https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 1 September 2009 (UTC) 36fc7ca95fe4c454faee61f27665c1b2608d3e10 698 697 2009-09-01T13:39:19Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == -Cern hostel: http://housing-service.web.cern.ch/housing-service/hostelwelc.html. If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. *Hint: If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended - as above. -St.Genis- (Lies between CERN and ALICE) * http://balladins.eu/fiche_hotel.php?id=166 * http://www.hotel-sofia.com/ -Between CERN and Geneve- * http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the Users office to get your contract fixed (http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010), afterwards you get your key card from the registration office (http://building.web.cern.ch/map/building?bno=55). * If you want a key to the Bergen office, go to the ALICE secreteriat and ask for it (http://building.web.cern.ch/map/building?bno=301, http://aliceinfo.cern.ch/Collaboration/General/secretariat/) * To rent a bicycle, go here: http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html, http://building.web.cern.ch/map/building?bno=124 * If you want to use the Bergen car, you need a CERN drivings license. Bring your drivings licence and go to the ALICE secreteriat. They will scan this in and request it for you. To get the CERN driving license, you need security course level 1+2, see below. You will receive an email that you should sign the request at http://edh.cern.ch, for this you need password as described below. == To do shifts == * You need a security course, this you can do online: (http://sir.cern.ch). * Request access for the control room in edh: https://edh.cern.ch --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the TPC&TRD shiftguide: http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf * HLT shiftguide: https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf * Book your shifts as: https://alicesms.cern.ch/ * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook (https://alice-logbook.cern.ch), ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 1 September 2009 (UTC) b04abc76d57b6b699b5c676b5600ee6f2361f96d 0 25 653 646 2009-08-24T12:05:14Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/mgc/ic.2006.2b/2006.2b_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Øvingsoppgaver i PHYS321 [[Category:Mikroelektronikk]] d2fd5fae8e8b444bf37b37a04d2d9bb2a5177cc9 6 204 657 2009-08-24T13:12:05Z Lli003 32 It is specification for TOR. wikitext text/x-wiki It is specification for TOR. dd74fc9e5d91dbb44eed595c2d21ecd89b3b1d50 6 205 658 2009-08-24T13:13:27Z Lli003 32 It is a instruction for TOR at P2 wikitext text/x-wiki It is a instruction for TOR at P2 0b90d4c2c21279c57eb0cc0045ea3b3f4296debc 2 206 659 2009-08-24T13:22:41Z Dfe002 7 Created page with 'Lijiao Liu' wikitext text/x-wiki Lijiao Liu 2f20d942afbb0f391ca9d5e33535adcd66056504 0 191 660 574 2009-08-25T07:15:08Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays primarily in collaboration with high school students and teachers, but master students will also be involved in the upgrade and extension of this system. == General description == To be provided... == More information == * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 55333e0239438c54f78b8054e61cace945533c39 661 660 2009-08-25T07:25:28Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts == General description == To be provided... == More information == * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 460ef893701b17713553e2cb077f18f3a4877f43 662 661 2009-08-25T07:26:21Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: A. Simple measurements with the CRT B. Building of a mini CRT at the high school laboratory == General description == To be provided... == More information == * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 9079f679b3fcac672993b7199897804a68f12776 663 662 2009-08-25T07:27:05Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == General description == To be provided... == More information == * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 7b969a7a3d5f60e87daf1ff6e8392e180f9615e4 664 663 2009-08-25T07:28:13Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == General description == To be provided... == More information == * Heidi's talk for TOF teachers 2009: * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 4f82d0bc2fa4d83371fc94e73aadb4c37c35b338 665 664 2009-08-25T07:30:44Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == The Cosmic Ray Telescope == To be provided... == High School Project == Plans for building a mini CRT CRT Measurements at IFT == More information == * Heidi's talk for TOF teachers 2009: to be added * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 7a5eaf207402a35949978c70266d67210a233506 666 665 2009-08-25T07:31:56Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == The Cosmic Ray Telescope == General description Possible Measurements Upgrade work Master thesis == High School Project == Plans for building a mini CRT CRT Measurements at IFT == More information == * Heidi's talk for TOF teachers 2009: to be added * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ ac26bf71894b9346d9ae4a149465fa19f6af9e37 667 666 2009-08-25T07:32:27Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == The Cosmic Ray Telescope == General description Possible Measurements Upgrade work Master thesis == High School Project == Plans for building a mini CRT CRT Measurements at IFT == More information == * Heidi's talk for TOF teachers 2009: to be added * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ 6f3937e74061dd56340bee8d945b7823798ae09f 674 667 2009-08-28T08:57:35Z Dfe002 7 /* More information */ wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == The Cosmic Ray Telescope == General description Possible Measurements Upgrade work Master thesis == High School Project == Plans for building a mini CRT CRT Measurements at IFT == More information == * Heidi's talk for TOF teachers 2009: to be added * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ * The original design report of the KTH cosmic ray project: http://www.particle.kth.se/SEASA/project.pdf * The cosmic ray telescope, a portable detector from the KTH: http://www.particle.kth.se/%7Epearce/CRT * The last link "Measuring the muon lifetime" (http://www.particle.kth.se/%7Epearce/muonlab) describes something we have prepared for in Bergen too. We have (most of) the material to build the intermediate layer, and a ready cut aluminium 1m^2 plate. This is part of the 'future work' for our CRT (in addition to the GPS-option). The construction is very simple, but more time will be needed on the analysis software development to have this implemented. 9c03b9d284b1d68b7b52e8bd0cc9ed1e42585273 6 207 671 2009-08-27T08:47:03Z St12151 15 Simple labview setup for reading out data from CAEN adc. wikitext text/x-wiki Simple labview setup for reading out data from CAEN adc. 6b996e4921cacbbfb117f38b37b78a05c604b41c 0 208 675 2009-08-28T12:02:35Z St12151 15 Created page with '== LabVIEW programs for detector-lab instruments == Several subVIs has been made to ease the use of instruments avaliable in the lab. Larger VIs then use these subVIs to set up a...' wikitext text/x-wiki == LabVIEW programs for detector-lab instruments == Several subVIs has been made to ease the use of instruments avaliable in the lab. Larger VIs then use these subVIs to set up a complete test-system that can control, monitor and capture data from experiments. == SubVIs == The following subVIs has been made for the CAEN ADC. In addition the VIs provided by CAEN for the PCI-link bridge is needed to use these. === CAEN ADC === After the CAENVME_INIT subVI has been started (parameters "1,0,0"), a handle to the PCI-bridge is given. This handle is used by all subsequent VIs to communicate with the ADC. For further information refer to the technical documents for the ADC. * ''''ADC_Reset'''' Resets the adc, stops data acqusition. * ''''ADC_setMode'''' Set bitdepth, enable interrupt and auto-start acqusition after readout. * ''''ADC_setTriggerMode'''' Sets internal/external/random trigger signal and edge. * ''''ADC_setPostTrig'''' Sets the window position in relation to the trigger (0-127, 64 equals trigger in centre). * ''''ADC_setTriggers'''' Enables the triggers, and sets the threshold voltage [-1, 1]V. * ''''ADC_StartAcqusition'''' Starts capturing data, needs only to be run once if ''auto restart AC'' is enabled in ADC_setMode. * ''''ADC_waitForInterrupt'''' Use this to pause loop until data is captured. Needs CAENVME_IRQEnable and interrupt enabled in ADC_setMode. * ''''ADC_readRAM * ''''Global_Settings'''' Global constants like ADC address and other shared variables are stored here. [[File:Adc-simple.png]] dc9a47fa92a8ce7c90efe052a35c3743b9dccc86 0 111 676 497 2009-08-28T13:55:33Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes |- |TTi EL155 |15V, 5A linear DC power supply | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 60f552d7ab9c05032f9258eceb386a37aef7ebc5 677 676 2009-08-28T14:08:10Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O ! |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |Optics department |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 | |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] |- |National Instruments VME-MXI-2 |VME controller | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} bd5ec8dbd11079695c56d0b37598bc17a8463096 678 677 2009-08-28T14:09:41Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |Optics department |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 | |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] | |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 5f072dd36132805a9a72c529a491af89cef9d5cb 679 678 2009-08-28T14:11:05Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |Optics department |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | | |- |TTi EL302D |30V, 2A dual linear DC power supply | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] | |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 | |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 02ecd9d56f9d170e2d3a0989fe70035019c5f629 0 197 681 636 2009-09-01T08:51:20Z Dfe002 7 wikitext text/x-wiki Some material for presentations should go here. Plots can be discussed during next meeting. Thesis: 4bc4bdf8786ba3a259e2cf20206df05d367b7226 683 681 2009-09-01T09:14:17Z Her065 20 wikitext text/x-wiki Some material for presentations should go here. Plots can be discussed during next meeting. Thesis: *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Characerization of Multipixel Avalanche Photodiodes, Spring 2009] 5cdf955e021a94579dbbe61dbc5d8c2e2f2b495f 684 683 2009-09-01T09:14:53Z Her065 20 wikitext text/x-wiki Some material for presentations should go here. Plots can be discussed during next meeting. Thesis: *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characerization of Multipixel Avalanche Photodiodes, Spring 2009] 07d96bd67e6b24ecc589317a4844238952124784 685 684 2009-09-01T09:15:17Z Her065 20 wikitext text/x-wiki Some material for presentations should go here. Plots can be discussed during next meeting. Thesis: *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] 05bc6a68ad7ac70b6f1d4e5e71e3104460f06e22 696 685 2009-09-01T12:56:19Z Her065 20 wikitext text/x-wiki Some material for presentations should go here. Plots can be discussed during next meeting. 8503982c8bb090370f08cfdbcf3e8790bb538505 6 209 682 2009-09-01T09:00:01Z Her065 20 Masterthesis Hege Austrheim Erdal Title: Characterization of Multipixel Avalanche Photodiodes wikitext text/x-wiki Masterthesis Hege Austrheim Erdal Title: Characterization of Multipixel Avalanche Photodiodes a714de662cf81e2ebdc02fe2519db8780d41638a 6 210 686 2009-09-01T09:24:28Z Her065 20 Hege's masterpresentation, 24th of June 2009 wikitext text/x-wiki Hege's masterpresentation, 24th of June 2009 8c10a682d66e9ed489df7c6541a43dbdc9abfbd8 0 21 687 635 2009-09-01T09:26:06Z Her065 20 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results 03.02.09] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. 1c1ce6b6e7278037f9142c3c486529e62c98bb0f 691 687 2009-09-01T12:16:43Z Her065 20 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009 - Meeting: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. 1bb3b4c2161deaa49b568b6ab51d3d01d210d4a8 694 691 2009-09-01T12:53:59Z Her065 20 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 3.2.2009 - Meeting: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. 0917cada3e39bea9075e8437be60696169c30add 0 211 695 2009-09-01T12:56:16Z Her065 20 Created page with '==Articles== Will be added later ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Charac...' wikitext text/x-wiki ==Articles== Will be added later ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] 1124117e653b72154d2bc377630f567dc2b5e339 700 695 2009-09-02T07:13:03Z Her065 20 wikitext text/x-wiki ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designsnext term of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations] '''SiPMs''' *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications] c9548cf889213e6b052ec5609c0f4affbe17c108 0 211 701 700 2009-09-02T07:19:03Z Her065 20 wikitext text/x-wiki ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designsnext term of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies) ] e4bba5b06160b45ca51b8e4d4906462bc34ab31d 702 701 2009-09-02T07:33:17Z Her065 20 wikitext text/x-wiki ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designsnext term of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET ] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies) ] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics] 51310889974a74d9c9cb64d22d463ee94cb5f293 703 702 2009-09-02T07:44:14Z Her065 20 wikitext text/x-wiki ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designsnext term of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET ] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies) ] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics] '''General about the photodetectors''' *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection] 9d5c4e3b1538b9ae709160765156b88ab6ad90f0 704 703 2009-09-02T07:58:23Z Her065 20 wikitext text/x-wiki ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout] *[ '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET ] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies) ] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter] fa2121fde4b36568774e7d75ab76a66001e6efc3 705 704 2009-09-02T08:24:41Z Her065 20 wikitext text/x-wiki ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET ] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies) ] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] fb27bfa80a4581dce186d5eaf4e8c67a3b3fcc9c 706 705 2009-09-02T08:34:23Z Her065 20 wikitext text/x-wiki Feel free to add thesis/articles! ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout, 2008] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier, 2001] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems, 2009] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation, 2004] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies), 2009] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics, 2007] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging, 2002] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection, 1996] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter, 2008] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] 1ca432d71d54abb240867b6938d59ec7dbbb8fef 707 706 2009-09-02T08:59:22Z Her065 20 wikitext text/x-wiki Feel free to add thesis/articles! ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout, 2008] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier, 2001] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems, 2009] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation, 2004] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies), 2009] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics, 2007] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging, 2002] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection, 1996] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter, 2008] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] '''PET''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1239645&isnumber=27794 Advantages of improved timing accuracy in PET cameras using LSO scintillator, 2002] *[http://www.iop.org/EJ/article/0031-9155/50/19/006/1.pdf First experimental results of time-of-flight reconstruction on an LSO PET scanner, 2005] *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=775565&isnumber=16852 Prospects for time-of-flight PET using LSO scintillator, 1999] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4P2S8W2-9-3&_cdi=5314&_user=107896&_orig=search&_coverDate=10%2F01%2F2007&_sk=994199997&view=c&wchp=dGLbVlz-zSkzk&md5=b4f9d0ef3f0dfb31a54c6c8dba480178&ie=/sdarticle.pdf Recent advances and future advances in time-of-flight PET, 2007] 91406d3c8537720831163e1026ab82e87285e3be 0 203 708 698 2009-09-02T12:23:58Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled Cern contract or Cern short term contract ** Short-term: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf ** Normal contract: http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == -[http://housing-service.web.cern.ch/housing-service/hostelwelc.html Cern hostel]. If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. *Hint: If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended - as above. -St.Genis- (Lies between CERN and ALICE) * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] -Between CERN and Geneve- * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to Cern == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at Cern == * Go to the [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 Users office] to get your contract fixed, afterwards you get your key card from [http://building.web.cern.ch/map/building?bno=55 the registration office]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secreteriat]''' [http://building.web.cern.ch/map/building?bno=301 Map] Go here for *key to the Bergen Office (if you want this) *CERN drivings licence, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course level 1+2, see below. When the secreteriate have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the [http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * [https://alicesms.cern.ch/ Book your shifts] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the [https://alice-logbook.cern.ch ALICE logbook], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 1 September 2009 (UTC) b6aaf207dbc8e05be038151b1bc6d057ebdc3a48 709 708 2009-09-02T12:33:33Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf Short-term] ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at CERN == * Go to the [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 Users office] to get your contract fixed, afterwards you get your key card from [http://building.web.cern.ch/map/building?bno=55 the registration office]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this) *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. == ALICE shiftwork == * Have a look into the [http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 1 September 2009 (UTC) f82c27b40ce5ed6dbc7aaf2a4bc933a7016e793c 715 709 2009-09-05T10:02:08Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf Short-term] ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at CERN == * Go to the [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 Users office] to get your contract fixed, afterwards you get your key card from [http://building.web.cern.ch/map/building?bno=55 the registration office]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this) *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. == ALICE shiftwork == * Have a look into the [http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 5 September 2009 (UTC) 42b869af018286e33f5d811b1f07ef8c50f931f8 726 715 2009-09-11T13:24:24Z Her065 20 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/ShortTermE.pdf Short-term]- NB! when the short-term contract expires, you have to hand in your CERN card at the end of your stay. In addition, the CERN account will be closed, normally within 1 month. If you want to have your CERN account (that includes your CERN-mail etc), you can extend the account by filling in a form for external participation. In any case, the CERN card have to be handed in, weekdays: Registration office (where you got it in the first place, see below) or to the guards at the main entrance. ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/UsersContractsInfo/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this) *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. == ALICE shiftwork == * Have a look into the [http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 5 September 2009 (UTC) 9b28caae040814c81a2b83633f99bfbe7d1db3d0 0 137 710 434 2009-09-02T13:16:49Z Mug004 27 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] === [[GroupSeminars|Group Seminars]] === === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] acfbe215348d399acf36d19b4dcac4c54146212d 711 710 2009-09-02T13:30:07Z Mug004 27 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 070327923e0b7cef9b562ae4738474f37797b30c 736 711 2009-09-22T11:13:52Z St11874 25 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 3b7968e9039bbcb689b6755981826797066fc43e 744 736 2009-09-22T15:15:21Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 4640a75050369e02da40bf4eb884a26c24ae6d88 764 744 2009-10-01T12:15:05Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 4133d3e868fc9b3636f97585964fdf1de58cc73e 0 21 712 694 2009-09-03T11:15:05Z Dfe002 7 /* Recent talks */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. b820293ff0a9c7b306c1338eca35d0d01fe3d363 713 712 2009-09-03T11:15:29Z Dfe002 7 /* Lab Equipment */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. be4dd6ba9ffb0eef1eb55ed1fb96a5c6f14b3bd1 728 713 2009-09-16T15:51:52Z Hsa061 18 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/d/d6/ Jostein: PET presentation] [[older presentations]] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. be7dd8ebd6d6e145f205c77e9b367897917284ba 729 728 2009-09-16T15:52:35Z Hsa061 18 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/d/d6/ Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. 97ac9ba2f23ccb1b00a0c3473b6aa0f5bddf3c18 0 212 714 2009-09-03T11:15:38Z Dfe002 7 Created page with '3.2.2009 - Meeting: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/ima...' wikitext text/x-wiki 3.2.2009 - Meeting: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results] bce7097c35d0dc8185b196a8185042474e13bc45 0 202 716 670 2009-09-08T06:59:13Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] dada19097a413e8d82eaea0b160f577b7250036b 727 716 2009-09-14T09:14:36Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] 2d4e96db4972e14d73aaf606df9116c3a48e616f 732 727 2009-09-22T09:51:47Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] == Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] da1c4dafb473135c19f53df406eec0b342ee19fb 735 732 2009-09-22T09:53:29Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[Category:Mikroelektronikk]] c9b56432b709d62e26c75f094f5e8a58dad3dca1 755 735 2009-09-28T13:36:30Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[ Eksempler/Oppgaver ]] [[Category:Mikroelektronikk]] b6bbd0bf8b9c010ca8e8fe506b3eec85d453b9a3 756 755 2009-09-28T13:36:45Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] === Kretssimulering === AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] [[ Eksempler/Oppgaver ]] [[Category:Mikroelektronikk]] ecc350b4c8412009c8efb5473289b98dd056ccd1 759 756 2009-09-29T08:54:55Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV]] [[Category:Mikroelektronikk]] 4fc21a76f7e27f9aa82af2b8b8b1633e80cc6fdd 6 213 717 2009-09-09T08:48:15Z Dfe002 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 3 719 548 2009-09-09T08:49:29Z Dfe002 7 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === [[How to run the RCU - DRORC - Busybox setup]] === === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[https://wikihost.uib.no/ift/images/9/95/Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Rikard Bolgen, Busybix User Guide]] <br> [[https://wikihost.uib.no/ift/images/b/bb/Rikard_Bolgen_-_Master_Thesis.pdf|Master Thesis, Rikard Bolgen]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 18636540797d13c566f45ff6010a477d6d01c45b 720 719 2009-09-09T08:50:31Z Dfe002 7 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === [[How to run the RCU - DRORC - Busybox setup]] === === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Rikard Bolgen, Busybix User Guide]] <br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bolgen]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 243fd7761004d3fc3ce732b0c34509ee00fa352d 721 720 2009-09-09T08:51:08Z Dfe002 7 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === [[How to run the RCU - DRORC - Busybox setup]] === === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Version 1.01: '''</li> </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] <br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 4a00793cbb1bcdb08afab45202dd594829e9992b 0 160 722 422 2009-09-09T13:44:46Z Tbu082 19 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[Software workshop, 09/09-09]] == Upcoming tutorials == == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] 1333e028bd7efe82fccdad0795977a29516c3fe6 0 215 723 2009-09-09T13:45:47Z Tbu082 19 Created page with 'The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == [[File:SoftwareWorkshop090909.pdf]]' wikitext text/x-wiki The meeting will take place in Bjarnes office at IFT Marc 19, 2009 at 12:30, and also on EVO (see below) == Presentation == [[File:SoftwareWorkshop090909.pdf]] b1268afd15d7ecfb8599bf13bbad4838555b9411 725 723 2009-09-09T13:47:32Z Tbu082 19 wikitext text/x-wiki The meeting took place in IFT room 316 09/09-09 @ 14.00 == Presentation == [[File:SoftwareWorkshop090909.pdf]] 9c9da27682d9af996f1d788dc3816b38523a6b22 6 216 724 2009-09-09T13:46:02Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 217 733 2009-09-22T09:52:13Z Nfyku 4 Created page with '% Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Kjetil Ullaland, 10. september 1996 ligning1='(Vout-Vgs)/Zc+gm*Vgs+...' wikitext text/x-wiki % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Kjetil Ullaland, 10. september 1996 ligning1='(Vout-Vgs)/Zc+gm*Vgs+Vout/Rl=0'; ligning2='(Vgs-Vout)/Zc+(Vgs-Vin)/Rs=0'; ligning1=subs(ligning1,'1/(j*w*C)','Zc'); ligning2=subs(ligning2,'1/(j*w*C)','Zc'); pretty(ligning1); pretty(ligning2); Vgs_solved=simplify(solve(ligning2,'Vgs')) pretty(Vgs_solved) ligning3=subs(ligning1,Vgs_solved,'Vgs'); Vout_solved=simplify(solve(ligning3,'Vout')) pretty(Vout_solved) c904b4642d1bc5dcb42fe4923c983a12bbd4e5e6 734 733 2009-09-22T09:52:55Z Nfyku 4 wikitext text/x-wiki <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Kjetil Ullaland, 10. september 1996 ligning1='(Vout-Vgs)/Zc+gm*Vgs+Vout/Rl=0'; ligning2='(Vgs-Vout)/Zc+(Vgs-Vin)/Rs=0'; ligning1=subs(ligning1,'1/(j*w*C)','Zc'); ligning2=subs(ligning2,'1/(j*w*C)','Zc'); pretty(ligning1); pretty(ligning2); Vgs_solved=simplify(solve(ligning2,'Vgs')) pretty(Vgs_solved) ligning3=subs(ligning1,Vgs_solved,'Vgs'); Vout_solved=simplify(solve(ligning3,'Vout')) pretty(Vout_solved) </pre> 9cdcddbabdab9515d1e20451daab2f60b133a7d8 0 1 751 459 2009-09-25T09:12:18Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 68166c48bdaea44d6eed6e617075e6cea17123a6 0 221 753 2009-09-25T09:18:20Z Nfyku 4 Created page with '== Nyttige ting == Her skal me samla alle dei små tinga me veit og dei tinga me ikkje visste at me kunne og dei tinga du ikkje visste naboen din ikkje visste du kunne. F.eks k...' wikitext text/x-wiki == Nyttige ting == Her skal me samla alle dei små tinga me veit og dei tinga me ikkje visste at me kunne og dei tinga du ikkje visste naboen din ikkje visste du kunne. F.eks korleis sette opp [[thunderbird]] som epostlesar [[Mal for PhD]] [[Mal for Master]] Nyttige [[nettsider]] [[LINUX]] tips og triks Info om [[printing]] [[Norske bokstaver i Latex]] Lagringsplassen vår på [[/Data/ift/ift_romfys1/]] I forbindelse med IPY-plakaten, ble det laget en enkel [[magnetosfærefigur]], som kan være fin å bruke i oppgaver (vektorgrafikk) Om romfysikk sine [[websider]] Hvordan få [[Fuview]] til å virke [[Category:Space physics]] 5df9cbd132ab3ae153c8c0b87d01b52f6da9cb08 0 222 754 2009-09-25T09:21:00Z Nfyku 4 Created page with '== ASIM - Atmosphere Space Interaction Monitor == ASIM is an experiment for the International Space Station (ISS) external facilities on the Columbus module. ASIM is aimed at th...' wikitext text/x-wiki == ASIM - Atmosphere Space Interaction Monitor == ASIM is an experiment for the International Space Station (ISS) external facilities on the Columbus module. ASIM is aimed at the study of high-altitude optical emissions from the stratosphere and mesosphere, the Transient Luminous Events (TLEs: Red Sprites, Blue Jets, Elves) and the Terrestrial Gamma Flashes (TGFs) (Neubert et al., 2006). ASIM has been through a Phase-A (Development and Design, 2004-2005) and a Phase-B (Breadboard and Feasibility, 2007-2009) study. In May 2009 the Program Board for Human Spaceflight and Exploration (PB-HME) decided that the ASIM payload shall be part of the ELIPS-3 program and allocated funding to ASIM from the program. A flight model of the ASIM payload will be built through Phase C/D starting early 2010. ---- [[Category:Space physics]] 1e2456b0547e02a3363b75063a69413413961aab 0 223 757 2009-09-28T13:42:02Z Nfyku 4 Created page with '== Øvingsoppgaver == === Problem 3.4 from Gray et.al. === For the common-source amplifier of Fig 3.12, calculate the small-signal voltage gain and the bias values of Vi and Vo ...' wikitext text/x-wiki == Øvingsoppgaver == === Problem 3.4 from Gray et.al. === For the common-source amplifier of Fig 3.12, calculate the small-signal voltage gain and the bias values of Vi and Vo where the small-signal voltage gain is unity with the transistor operating in the active region. [[Spice deck]] [[Category:Mikroelektronikk]] e9bf226c6ef129734bd8d9adb2720e1cd26240d1 0 224 758 2009-09-28T13:42:53Z Nfyku 4 Created page with '<pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage ...' wikitext text/x-wiki <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD VSS 3 * Transistor * Drain Gate Source Bulk MN1 Out In VSS VSS nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out VSS 0.1p * Voltage source * from to volts VI In VSS DC 1.281 AC 1 * * Models * .model nmos nmos level=1 VT0=0.6 KP=200u LAMBDA=0 * * Setup * .options nomod nopage .width OUT=80 .connect vss 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] 713349e199274f95bcc93909ca6b47a0110e8fa5 760 758 2009-09-29T08:57:24Z Nfyku 4 wikitext text/x-wiki <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD VSS 3 * Transistor * Drain Gate Source Bulk MN1 Out In VSS VSS nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out VSS 0.1p * Voltage source * from to volts VI In VSS DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0.2 + TOX=10e-9 PHI=0.93 GAMMA=0.6 + CJ=9.8E-5 PB=0.72 MJ=0.36 + CJSW=2.2E-10 MJSW=0.1) * * Setup * .options nomod nopage .width OUT=80 .connect vss 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] bc99acd0c71655ef6f781b8d67d8e9e88d3a86be 0 191 761 674 2009-10-01T08:31:38Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == The Cosmic Ray Telescope == General description Possible Measurements Upgrade work Master thesis == High School Project == Prinsippet for Kosmisk Stråle Teleskop (CRT) ---- To lag av scintillatorer ligger over hverandre så når en kosmisk stråle passerer så gir det et signal i begge scintillatorene. Plan for å bygge et mini-CRT ---- Materialer og kostnader ---- CRT Målinger ved IFT ---- == More information == * Heidi's talk for TOF teachers 2009: to be added * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ * The original design report of the KTH cosmic ray project: http://www.particle.kth.se/SEASA/project.pdf * The cosmic ray telescope, a portable detector from the KTH: http://www.particle.kth.se/%7Epearce/CRT * The last link "Measuring the muon lifetime" (http://www.particle.kth.se/%7Epearce/muonlab) describes something we have prepared for in Bergen too. We have (most of) the material to build the intermediate layer, and a ready cut aluminium 1m^2 plate. This is part of the 'future work' for our CRT (in addition to the GPS-option). The construction is very simple, but more time will be needed on the analysis software development to have this implemented. d98bd8de2cca29bb29623d2fcb8854ca3dd4441c 762 761 2009-10-01T08:37:09Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == The Cosmic Ray Telescope == General description Possible Measurements Upgrade work Master thesis == High School Project == Prinsippet bak et Kosmisk Stråle Teleskop (CRT) ---- To lag av scintillatorer ligger over hverandre så når en kosmisk stråle passerer så gir det et signal i begge scintillatorene. Hver av scintillatorene er koblet til et photomulitplikator rør som sender det registrerte signalet til et elektronikk kort. Elektronikk kortet kan ha en teller som Plan for å bygge et mini-CRT ---- Materialer og kostnader ---- 2 Scintillatorer 2 PM rør 1 elektronikk kort (lages i sammarbeid med UiB) 1 kasse med holdere for scintillatorene Ledninger Så skolens utgifter er til de 2 PM rørene og eventuelt scintillatorene hvis ikke vi kan bidra med det fra UiB. CRT Målinger ved IFT ---- == More information == * Heidi's talk for TOF teachers 2009: to be added * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ * The original design report of the KTH cosmic ray project: http://www.particle.kth.se/SEASA/project.pdf * The cosmic ray telescope, a portable detector from the KTH: http://www.particle.kth.se/%7Epearce/CRT * The last link "Measuring the muon lifetime" (http://www.particle.kth.se/%7Epearce/muonlab) describes something we have prepared for in Bergen too. We have (most of) the material to build the intermediate layer, and a ready cut aluminium 1m^2 plate. This is part of the 'future work' for our CRT (in addition to the GPS-option). The construction is very simple, but more time will be needed on the analysis software development to have this implemented. 57a7350a73954e9842265ef5e13735e449c8632c 763 762 2009-10-01T08:38:27Z Hsa061 18 wikitext text/x-wiki == Concept == At the subatomic research group we have a muon spectrometer to be used for measurements of cosmic rays. The Cosmic Ray Telescope (CRT) is a scintillator detector of a total area of 4 m2 which is designed and constructed to register muons that originate from the decay of mesons created by primary cosmic radiation. The CRT is primarliy designed and commissioned to be used in exercises for undergraduate students and for high school students. The setup will also provide master student project to upgrade and extend this system and to do more advanced cosmic ray studies. During 2009 our plans are to define a high school project associated with our muon spectrometer. It will consist of two parts: * Simple measurements with the CRT * Building of a mini CRT at the high school laboratory == The Cosmic Ray Telescope == General description Possible Measurements Upgrade work Master thesis == High School Project == '''Prinsippet bak et Kosmisk Stråle Teleskop (CRT)''' ---- To lag av scintillatorer ligger over hverandre så når en kosmisk stråle passerer så gir det et signal i begge scintillatorene. Hver av scintillatorene er koblet til et photomulitplikator rør som sender det registrerte signalet til et elektronikk kort. Elektronikk kortet kan ha en teller som '''Plan for å bygge et mini-CRT''' ---- '''Materialer og kostnader''' ---- * 2 Scintillatorer * 2 PM rør * 1 elektronikk kort (lages i sammarbeid med UiB) * 1 kasse med holdere for scintillatorene * Ledninger Så skolens utgifter er til de 2 PM rørene og eventuelt scintillatorene hvis ikke vi kan bidra med det fra UiB. CRT Målinger ved IFT ---- == More information == * Heidi's talk for TOF teachers 2009: to be added * Øyvind's thesis which gives a good description of our setup: http://web.ift.uib.no/~lipniack/theses/oyvind_satre_muon_telescope.pdf * KTH has an overview of their cosmic ray project on http://www.particle.kth.se/SEASA/ * The original design report of the KTH cosmic ray project: http://www.particle.kth.se/SEASA/project.pdf * The cosmic ray telescope, a portable detector from the KTH: http://www.particle.kth.se/%7Epearce/CRT * The last link "Measuring the muon lifetime" (http://www.particle.kth.se/%7Epearce/muonlab) describes something we have prepared for in Bergen too. We have (most of) the material to build the intermediate layer, and a ready cut aluminium 1m^2 plate. This is part of the 'future work' for our CRT (in addition to the GPS-option). The construction is very simple, but more time will be needed on the analysis software development to have this implemented. 7bae30c0dc7fff39fdda4e16402ad3048e6ef3fe 0 225 765 2009-10-01T12:15:35Z Tbu082 19 Created page with '== ATLAS outreach ==' wikitext text/x-wiki == ATLAS outreach == 70b0156a44d74f147af362769b9123b2822dba2e 766 765 2009-10-01T12:16:10Z Tbu082 19 wikitext text/x-wiki == ATLAS outreach == === Talks === === Images === 2057dbb4784db4363c61fccf6bf1c35193b1e07f 767 766 2009-10-01T12:16:25Z Tbu082 19 wikitext text/x-wiki == ATLAS outreach == === Talks === === Images === === Links === 8a7822700f05cb630d09da1d418f491af49044b0 2 226 768 2009-10-02T09:41:10Z Tbu082 19 Created page with '=== Kristine Helle ===' wikitext text/x-wiki === Kristine Helle === 06737329af916661b36bfe630d6fd7a85e228775 2 227 770 2009-10-06T09:56:26Z Dfe002 7 Created page with 'Jostein Sæterstøl' wikitext text/x-wiki Jostein Sæterstøl 0d4ca00de89a3e31efe26f6df598bbad95fba95c 6 228 771 2009-10-06T10:04:35Z Jsa038 34 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 21 772 729 2009-10-06T10:05:39Z Jsa038 34 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. 8e6ff2f8c6a7c609fd47c6191c421c57c2ff7eda 0 139 773 451 2009-10-06T10:12:29Z Hsa061 18 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster - Thomas * Susy tau poster - Alex & Therese * Monitoring poster - Arshak * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 3d49db7c92e2b95cf112cd71e9424575db9a2cb7 774 773 2009-10-06T10:15:38Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster [landscape, a0] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 fbedbf91db21d1409f3fd13ca2079a79fb0ea546 775 774 2009-10-06T10:16:26Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster [landscape, a0] [[File:[taupairs.pdf]]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 814478c4826e40276b5a753b2ec014f4c4f6d897 776 775 2009-10-06T10:16:51Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [File:[taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 fed9a1af27f7188c9b124b25586b8429bd2a7613 777 776 2009-10-06T10:17:04Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) taupairs.pdf - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 5cade800b6f383123a4c84de4fb860224cf23ccd 778 777 2009-10-06T10:17:17Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 d373f49f93b061213647b4e9294d09617075700a 780 778 2009-10-06T10:19:05Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf|taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 96eaa4e539fb7706112b9b77201435ca07bfad19 781 780 2009-10-06T10:20:44Z Ato061 22 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf|taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 1bf46f287e5768878258983a04627cfcb930fa27 782 781 2009-10-06T10:22:43Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] * BSF poster - Heidi * Outreach poster (optional) [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 16e106b007e43fd27eb15c43e66120600ed8e983 783 782 2009-10-06T10:28:38Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- Alex & Therese * Monitoring poster - Arshak [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] * BSF poster - Heidi * Outreach poster (optional) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 42d0dbf1547b50500fd83da47f90571afc5c5cea 786 783 2009-10-06T11:08:25Z St11874 25 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster - Arshak [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] * BSF poster - Heidi * Outreach poster (optional) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 51e4b3b9db471facad0578b692960f82c7677ea2 790 786 2009-10-06T11:49:11Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster - Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster - Arshak [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] (+computer slide show) * BSF poster - Heidi * Outreach poster (optional) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 a71bc6806fb73dc326c315a27eb7bc6ee11a842d 791 790 2009-10-06T11:53:58Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster [[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster - Arshak [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] (+computer slide show) * BSF poster - Heidi * Outreach poster (optional) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 3dfd1c49374fa6d9155a73ff563c4a98ce3254e8 793 791 2009-10-06T11:55:05Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster (portrait, a0)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, a0) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster [landscape, a0]- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster - Arshak [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] (+computer slide show) * BSF poster - Heidi * Outreach poster (optional) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 e0045b8d1bbf28d03954a6190f35295d0aa3ccfc 794 793 2009-10-06T11:56:33Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == Review - Posters: * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi * Outreach poster (optional) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 2ec1d03856739ac6655d5c44edecea206594b6e6 795 794 2009-10-06T11:59:05Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == === Review - October 9 2009 - Posters === All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi * Outreach poster (optional) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 4b10c0d1e3164cf4f0de06a9fd5b6ed102b0c410 796 795 2009-10-06T12:05:59Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == === Review - October 9 2009 - Posters === All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional print at CERN) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 ebe2975e7909de7c174382496347adf4390ac7d6 797 796 2009-10-06T12:06:52Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == === Review - October 9 2009 - Posters === All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional, portrait, print at CERN) Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 4803edcbb49eae281a01bfabc6506fb1a7229980 807 797 2009-10-06T21:48:52Z Hsa061 18 wikitext text/x-wiki == Particle Physics Group Meetings == === Review - October 9 2009 - Posters === All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional, portrait, print at CERN) * 3D poster (for the laboratory)[[File:3D.pdf] Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 459d0821a76d5a0f953701ae4f8e7cfe0b41631a 811 807 2009-10-07T10:02:31Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == [[October 9 2009 review - poster session]] === Review - October 9 2009 - Posters === All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional, portrait, print at CERN) * 3D poster (for the laboratory)[[File:3D.pdf] Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 --- [[Shifts/OTP/fimm group meeting May 5, 2009]] [[SUSY/Tau analysis meeting March 12, 2009]] [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 62b8bf3351533b33723de8ba54592f04e4df5289 813 811 2009-10-07T10:03:18Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 30db45a7a336724d8177794293e23d4e30cfc9e2 814 813 2009-10-07T10:03:49Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 [[ParticlePhysicsGroupMeetings|Back to meeting page]] 63eef46d2afa8b4ef17cec74158d35188cd856f1 815 814 2009-10-07T10:04:40Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 488ad42dd02edf9404d7a79eed82641fa60f6072 6 229 779 2009-10-06T10:18:30Z Tbu082 19 Studies of Tau Pairs. Poster for review session, 9 oct 2009. wikitext text/x-wiki Studies of Tau Pairs. Poster for review session, 9 oct 2009. 45c93ec329271b463296061b0203fdf7e3b9796a 788 779 2009-10-06T11:40:28Z Tbu082 19 uploaded a new version of "[[File:Taupairs.pdf]]": Review of ATLAS Tau Pair Analysis oct 9 2009. Minor changes wikitext text/x-wiki Studies of Tau Pairs. Poster for review session, 9 oct 2009. 45c93ec329271b463296061b0203fdf7e3b9796a 805 788 2009-10-06T15:49:26Z Tbu082 19 uploaded a new version of "[[File:Taupairs.pdf]]": Some changes to tau<->mu text wikitext text/x-wiki Studies of Tau Pairs. Poster for review session, 9 oct 2009. 45c93ec329271b463296061b0203fdf7e3b9796a 806 805 2009-10-06T15:50:45Z Tbu082 19 uploaded a new version of "[[File:Taupairs.pdf]]": Fixed tau<->mu text wikitext text/x-wiki Studies of Tau Pairs. Poster for review session, 9 oct 2009. 45c93ec329271b463296061b0203fdf7e3b9796a 6 230 785 2009-10-06T11:07:04Z St11874 25 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 231 787 2009-10-06T11:09:23Z St11874 25 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 810 787 2009-10-07T09:50:32Z Tbu082 19 uploaded a new version of "[[File:SUSY with tau poster.pdf]]": Final version wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 137 789 764 2009-10-06T11:48:28Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] aa3ac2eed4025c17861fa4f4409758e2d19580c0 801 789 2009-10-06T13:50:54Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] b3307a3ec0c7c1b295965193e66974c922652b81 6 232 792 2009-10-06T11:54:28Z Tbu082 19 Theory poster for review 9 oct 2009 wikitext text/x-wiki Theory poster for review 9 oct 2009 e584676ca7ea62a589800242b7da31c79b807898 2 233 798 2009-10-06T12:10:16Z Dfe002 7 Created page with 'Magne Munkejord' wikitext text/x-wiki Magne Munkejord 99ab59445525b161154ac3e2bf4f21e3b4b39c9f 0 234 802 2009-10-06T13:51:28Z Tbu082 19 Created page with '== Theses, Notes, Publications, ... == === Master theses === * Kent-Olav Skjei -' wikitext text/x-wiki == Theses, Notes, Publications, ... == === Master theses === * Kent-Olav Skjei - 90a03da77495182d29115b07a6fde2a0810846c1 803 802 2009-10-06T13:54:21Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets [[File:Kent-Olav_Skjei-Thesis.pdf]] c08870506c455d48de04584b5cbbaa24438587dd 6 235 804 2009-10-06T13:54:48Z Tbu082 19 Kent Olav Skjeis Master Thesis wikitext text/x-wiki Kent Olav Skjeis Master Thesis 1a8df758a4bcf68eade3b20ee76c0a431bc383e9 6 236 808 2009-10-06T21:51:27Z Hsa061 18 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 237 809 2009-10-07T09:15:23Z Hsa061 18 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 238 812 2009-10-07T10:02:41Z Tbu082 19 Created page with 'All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren *...' wikitext text/x-wiki All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional, portrait, print at CERN) * 3D poster (for the laboratory)[[File:3D.pdf] Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 44f0c5826d207fd3ea6b3bb9d70655dde26e8a80 816 812 2009-10-07T10:04:56Z Tbu082 19 wikitext text/x-wiki All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional, portrait, print at CERN) * 3D poster (for the laboratory)[[File:3D.pdf] ---- Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 ---- [[ParticlePhysicsGroupMeetings|Back to meeting page]] 38c5631dae57dcd391661b0bac2cc97d35fa0219 817 816 2009-10-07T10:16:33Z Hsa061 18 wikitext text/x-wiki All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional, portrait, print at CERN)[[File:Outreach.pdf]] * 3D poster (for the laboratory)[[File:3D.pdf] ---- Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 ---- [[ParticlePhysicsGroupMeetings|Back to meeting page]] 0bdc742df4aaaae3358b1f25ee4b4ec63ceca0ab 818 817 2009-10-07T10:16:58Z Hsa061 18 wikitext text/x-wiki All posters are in a0 format. For prints from CERN deadline is lunch 8/8-09. * Theory poster (portrait, print at CERN)[[File:poster-osland.pdf]]- Per * B-physics poster - Maren * Standard Model tau poster (landscape, print at CERN) [[File:taupairs.pdf]] - Thomas (representing Peter, Arshak, Ørjan, Alette, Anna and Bjarne) * Susy tau poster (landscape, print at CERN)- [[File:SUSY_with_tau_poster.pdf]] - Alex & Therese * Monitoring poster (portrait, printed allready) [http://web.ift.uib.no/~tonoyan/CHEP_2009_new.pdf Commissioning of ATLAS reco software] - Arshak (+computer slide show) * BSF poster - Heidi (portrait, print at CERN) * Outreach poster (optional, portrait, print at CERN)[[File:Outreach.pdf]] * 3D poster (for the laboratory)[[File:3D.pdf]] ---- Connect to skype chat for poster session using this link: http://www.skype.com/go/joinpublicchat?skypename=thomas%2eburgess&topic=Posters&blob=lTdzCuO6b3SGwD1Dig__P0VNHCKMVUpi2SCVdtfzs-NFPCfqG1fZjgFbbUxmcvpkH9adx95Ahx3R6LxUvvJ30_2ml-SHkYKRiVK1uOlJgxYa1Havc2O2 ---- [[ParticlePhysicsGroupMeetings|Back to meeting page]] b559ecb95fff03ebb60a11b8598f5b7fb6056b18 0 111 819 679 2009-10-08T10:54:02Z Dfe002 7 /* Low Voltage */ wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |Optics department |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | |2x Anja |- |TTi EL302D |30V, 2A dual linear DC power supply | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 | |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} ac4542f36fefa1111491b7431e18320b24e8966b 0 3 821 721 2009-10-09T14:56:23Z St09909 38 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. === [[How to run the RCU - DRORC - Busybox setup]] === === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Revision 31 : '''</li> [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] <br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 25b35df380198494e0c5ae1cc02fe3bd6002abf6 0 196 822 630 2009-10-12T07:30:05Z Dfe002 7 wikitext text/x-wiki Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find money for it. ==XYZ-table setup== * <s>1µm fiber to scan the detectors.<s> * optical gating grid to calibrate the XYZ-table. [[User:Dfe002|Dominik]] 11:41, 19 August 2009 (UTC) 902783953245942d55a3688b3b7341b7f8034dc2 0 196 823 822 2009-10-12T07:30:17Z Dfe002 7 wikitext text/x-wiki Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find money for it. ==XYZ-table setup== * <s>1µm fiber to scan the detectors.</s> * optical gating grid to calibrate the XYZ-table. [[User:Dfe002|Dominik]] 11:41, 19 August 2009 (UTC) 5dce7131b0b6ffaae6deac9ca937586776e5b20e 824 823 2009-10-12T07:30:37Z Dfe002 7 wikitext text/x-wiki Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find money for it. ==XYZ-table setup== * <s>1µm fiber to scan the detectors.</s> * optical gating grid to calibrate the XYZ-table. [[User:Dfe002|Dominik]] 07:30, 12 October 2009 (UTC) 58797b78cac356f32e85af4ba3323825c6269914 863 824 2009-11-02T09:13:33Z Dfe002 7 wikitext text/x-wiki Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find money for it. ==XYZ-table setup== * <s>1µm fiber to scan the detectors.</s> * optical gating grid to calibrate the XYZ-table. * New camera for the X/Y table [[User:Dfe002|Dominik]] 07:30, 12 October 2009 (UTC) 598f8b2d1c1783e4b9d78a66bfdb190890ecc7f9 0 21 825 772 2009-10-12T07:31:23Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. * [[Retningslinjer for bruk av kapslede kilder ved IFT]] == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 16.-18.09.09: CALICE Collaboration Autumn Meeting, Lyon * 21.-25.09.09: TWEPP 09, Paris, http://twepp09.lal.in2p3.fr/ * 28.9.-2.10.09: IRTG/Forskerskole in Oslo, visit of Sintef * 30.09.-2.10.09: RD09, Florence, http://www.fi.infn.it/conferenze/rd09/ === For internal use === [[material]] that can be used in official presentations. 94912d8cab14b2e5dac1aaa29f6ba04c6fcd4756 827 825 2009-10-12T09:24:26Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Resources == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * Our [http://https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab * Our weekly labmeeting is Tuesdays 11:15 in room 332. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * none at the moment === For internal use === [[material]] that can be used in official presentations. e1c12040091b255069804bfd95b2f4a70f73261c 841 827 2009-10-15T08:52:30Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Resources == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * Our [http://https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab * Our weekly labmeeting is Tuesdays 11:15 in room 332. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 11.12.09: MedViz seminar series - presentation of PET related projects, 1 hour * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 15.02. - 20.02.10: Vienna conference on Instrumentation (http://vci.hephy.at/2010/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany (http://indico.cern.ch/conferenceDisplay.py?confId=62885) === For internal use === [[material]] that can be used in official presentations. 2c4cb9c0990a728cad31fd355b7f3b734c011d86 852 841 2009-10-21T11:31:07Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Resources == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * Our [http://https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab * Our weekly labmeeting is Tuesdays 11:15 in room 332. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 11.12.09: MedViz seminar series - presentation of PET related projects, 1 hour * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 02.01. - 08.01.10: Spåtind meeting on particle physics (http://indico.cern.ch/event/spaatind-2010) * 15.02. - 20.02.10: Vienna conference on Instrumentation (http://vci.hephy.at/2010/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany (http://indico.cern.ch/conferenceDisplay.py?confId=62885) === For internal use === [[material]] that can be used in official presentations. 6da1fca4d776f1f90083e16c04c464a2ccd44de2 872 852 2009-11-03T09:29:54Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Resources == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * Our [http://https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab * Our weekly labmeeting is Tuesdays 11:15 in room 332. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 11.12.09: MedViz seminar series - presentation of PET related projects, 1 hour * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 02.01. - 08.01.10: Spåtind meeting on particle physics (http://indico.cern.ch/event/spaatind-2010) * 15.02. - 20.02.10: Vienna conference on Instrumentation (http://vci.hephy.at/2010/) * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany (http://indico.cern.ch/conferenceDisplay.py?confId=62885) === For internal use === [[material]] that can be used in official presentations. 0110b2ee79bdf8d1a421b71afc282601fc4eeb2d 873 872 2009-11-03T09:36:48Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Resources == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * Our [http://https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab * Our weekly labmeeting is Tuesdays 11:15 in room 332. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 11.12.09: MedViz seminar series - presentation of PET related projects, 1 hour * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 02.01. - 08.01.10: Spåtind meeting on particle physics (http://indico.cern.ch/event/spaatind-2010) * 15.02. - 20.02.10: Vienna conference on Instrumentation - Deadline 16.11.09. (http://vci.hephy.at/2010/) * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany === For internal use === [[material]] that can be used in official presentations. 87fb760ababbbd3e01e01e1ee3dab84a62994892 874 873 2009-11-03T09:44:26Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [http://https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab * Our weekly labmeeting is Tuesdays 11:15 in room 332. == Recent talks == 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 11.12.09: MedViz seminar series - presentation of PET related projects, 1 hour * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 02.01. - 08.01.10: Spåtind meeting on particle physics (http://indico.cern.ch/event/spaatind-2010) * 15.02. - 20.02.10: Vienna conference on Instrumentation - Deadline 16.11.09. (http://vci.hephy.at/2010/) * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany === For internal use === [[material]] that can be used in official presentations. e3fd79fde6bfd1953ffb0ba1b155404da56d2c31 0 239 826 2009-10-12T07:48:39Z Dfe002 7 Created page with '# Alle flyttbare strålingskilder skal oppbevares i en av instituttets blysafer eller annet spesifisert avskjermet kammer når de ikke er i bruk. # Inn- og utlogg skal føres nå...' wikitext text/x-wiki # Alle flyttbare strålingskilder skal oppbevares i en av instituttets blysafer eller annet spesifisert avskjermet kammer når de ikke er i bruk. # Inn- og utlogg skal føres når kildene tas ut fra lagringsplass for bruk og returneres. # Etter avsluttet bruk skal kildene bringes tilbake til oppbevaringssted så fort som mulig. Ingen kilder skal unødig bli riggende rundt i laboratoriene. Kildene skal fortrinnsvis bringes tilbake til lager ved arbeidstidens slutt. Dersom kilder mad aktivitet under 1MBq skal benyttes flere dager i strekk kan de bli liggende over natten i apparatoppstilling dersom dette ikke kan medføre nevneverdig dosebelastning for personer som skulle oppholde seg i laboratoriet. Stråleområdet merkes i slike tilfeller med propelltape eller skilt, og laboratoriet skal låses når det forlates. # Når kildene er i bruk, så skal det sørges for avskjerming for å unngå unødig dosebelastning. # Dersom de benyttede kildene har en aktivitt over "unntaksgrensen" (1 Mbq for de fleste kilder), må også dosebelastning vurderes. Dette gjøres enklest ved å utføre en måling med Geigerteller som er kalibrert slik at dosebelastning kan avleses direkte (vanligvis i µSv/time). IFT hart en teller som kan utlånes til dette formål. Unntaksgrenser finnes i vedlegg til Strålevernsforskriften. # Hvis bruken av kilder kan gi en dosebelasting some er over 1 mSv/år skal bruker utstyres med dosimeter. Vurdering av antatt årlig dosebelastning foretas av instituttets strålevernskoordinator i samråd med aktuell forskningsgruppe. Dosimeter bestilles ved henvendelse til Margun Solheim. # Det er veileder eller kursleder sitt ansvar å påse at disse retningslinjer blir fulgt når studenter arbeider med strålekilder. Bjarne Stugu er Strålevernskoordinator ved IFT 9440f3cac0bf9cff28b119fec532056a25e98983 0 3 828 821 2009-10-14T07:45:00Z St09909 38 /* How to run the RCU - DRORC - Busybox setup */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC. Components in LAB setup : * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. [[How to run the RCU - DRORC - Busybox setup]] === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> === Download Section === Specification document:<br> [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] <br> Source files:<br> [http://svn.ift.uib.no/svn/busybox_firmware SVN database] | [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database Trigger Receiver] <br> BusyBox firmware:<br> <ul> <li>'''Revision 31 : '''</li> [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] </ul> <br> VHDL source code for Trigger Receiver module:<br> <ul> [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/vhdl/ VHDL code for Trigger Receiver] </ul> <br> DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] <br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] cb056dc59641d3cf2fc434544a7cc4bd96b35c08 829 828 2009-10-14T08:01:33Z St09909 38 /* Download Section */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC. Components in LAB setup : * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. [[How to run the RCU - DRORC - Busybox setup]] === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> == BusyBox Firmware == === Download Section === [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 : [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] DCS board firmware for BusyBox:<br> <ul> [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] </ul> <br> Related documents for BusyBox:<br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] <br> [[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] <br> [[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] <br> [[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] <br> [[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] dd8b1ff83b3a0aa9af13eb4171b0358f171ef679 830 829 2009-10-14T08:06:15Z St09909 38 /* Compiled BusyBox Firmware Versions */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC. Components in LAB setup : * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. [[How to run the RCU - DRORC - Busybox setup]] === Version history === '''1.0 ''' <br> <ul> <li> Magne Munkejord </li> </ul> <br> == BusyBox Firmware == === Download Section === [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 : [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 354ca4d27c12f3fe4f98490ee94a42c79d6492b3 831 830 2009-10-14T08:12:33Z St09909 38 /* BusyBox Hardware tests at UiB */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == === Download Section === [[Media:User_guide_busybox.pdf‎‎ | user_guide_busybox.pdf]] ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 : [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 8ad411cc1d7bd353dc791b22c422f03e7c84638e 832 831 2009-10-14T08:13:11Z St09909 38 /* Download Section */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 : [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] : [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 1e647c2d5500c3df87ab7772bdb8b373bf9fe210 833 832 2009-10-14T09:40:37Z St09909 38 /* BusyBox Firmware */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== Compiled BusyBox Firmware Versions ==== ====== BusyBox FPGAs ====== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ;Revision 31 [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 81eb2fd137af0d05d290c5275d6d2daabe07a409 834 833 2009-10-14T09:58:08Z St09909 38 /* Generating FPGA configuration files from source code */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== Compiled BusyBox Firmware Versions ==== ====== BusyBox FPGAs ====== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ;Revision 31 [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== [[Electronics_for_the_Time_Projection_Chamber_(TPC)#Download_Section|BUSYBOX]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 9d4bb7872ec585b22d4365b864858b5a5a33f51e 835 834 2009-10-14T11:10:01Z St09909 38 /* DCS board firmware for BusyBox */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== Compiled BusyBox Firmware Versions ==== ====== BusyBox FPGAs ====== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ;Revision 31 [http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] [http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ===== DCS board firmware for BusyBox ===== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 8d5b321e5ff234dad00e19713001ad3d91a21486 836 835 2009-10-14T11:31:31Z St09909 38 /* Compiled BusyBox Firmware Versions */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ==== BusyBox FPGAs ==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 01add063391251e786c540ab7b61ac73155215f5 837 836 2009-10-14T11:34:07Z St09909 38 /* BusyBox Firmware */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] cffa23aba52858720b7c09abb426704420ac0510 846 837 2009-10-20T15:09:42Z St09909 38 /* BusyBox Firmware */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[BusyBoxRegisters]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] d7891837539f94c58a9f597545c8e65531f931fd 847 846 2009-10-20T15:10:15Z St09909 38 /* BusyBox Firmware */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 897a3fa8a543e8296d85e3f40d2912531b92ab24 848 847 2009-10-20T15:11:35Z St09909 38 /* BusyBox Firmware */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] cb45b05ad5f22e5189f9f451c9191a925df688fb 856 848 2009-10-22T12:42:05Z St09909 38 /* Compiled BusyBox Firmware Versions */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ;Revision 35 ;:* Compiled with stricter constraints and higher effort settings (100 degrees celsius, 45 MHz, 1.14 V) ;:* Added "number of channels" status register. ;:* Added Stress test mode for testing only. (Disabled by default.) ;:;Download ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] e921d9236611bcf8e3c38e7ff60aa06bf585f5cc 858 856 2009-10-28T09:28:00Z St09909 38 /* Compiled BusyBox Firmware Versions */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] <!-- ;Revision 35 ;:* Compiled with stricter constraints and higher effort settings (100 degrees celsius, 45 MHz, 1.14 V) ;:* Added "number of channels" status register. ;:* Added Stress test mode for testing only. (Disabled by default.) ;:;Download ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga2.bit busybox_fpga2.bit] --> ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] [[Category:Alice]] [[Category:Trigger]] 48105c1a0c39a450458995b37c1db01d35350cf8 0 139 838 815 2009-10-14T13:55:07Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 ad5cfe0038628d7e2e876da65f494e1cfe97e90b 866 838 2009-11-02T15:12:53Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[November 2 2009 seminar - 3D detectors and the lab - Dominik, Lars-Halvor, Kristine]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 b0cb0c526a97b5bd3d7d6e0fe91baaf470e0bdd2 867 866 2009-11-02T15:13:08Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[November 2 2009 seminar - 3D detectors and the lab - Dominik, Lars-Halvor, Kristine]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 a41b259d36563c945d0779e20c88718ba8cc449d 868 867 2009-11-02T15:13:42Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 83dce29ea2945bfca7c6b113c7f728b5503069f6 0 240 839 2009-10-14T13:56:23Z Tbu082 19 Created page with 'Presentation pdf: [[file:TauPair-Seminar-2009-08-13.pdf]]' wikitext text/x-wiki Presentation pdf: [[file:TauPair-Seminar-2009-08-13.pdf]] c01d163fa2580d0f45a7e2880962ee28c10f9991 865 839 2009-11-02T15:11:39Z Tbu082 19 wikitext text/x-wiki Presentation pdf: [[file:TauPair-Seminar-2009-08-13.pdf]] [[ParticlePhysicsGroupMeetings|Back to meetings]] efd50c1781e6f4562ce5a0beb686aaab70ea6749 6 241 840 2009-10-14T13:56:34Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 242 843 2009-10-20T15:02:49Z St09909 38 Created page with '{| border="1" cellpadding="1" cellspacing="0" |colspan="5"| ====Busy Box Status and Contol Registers==== |- !Address !Read/Write !Name !Description !Default Value |- |0x0001 |RW ...' wikitext text/x-wiki {| border="1" cellpadding="1" cellspacing="0" |colspan="5"| ====Busy Box Status and Contol Registers==== |- !Address !Read/Write !Name !Description !Default Value |- |0x0001 |RW |TX module |For sending messages to DRORCs. Bit 7-0 is TX data. Bit 15-8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |TBD |- |0x1XXX |RW |RX memory |Memory where all messages received from DRORCs will be stored. |TBD |- |0x2000 |R |RX memory pointer |Holds the value where the next message will be written in RX memory. |TBD |- |0x2001 |R |EventID count |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |TBD |- |0x2002 |R |Current EventID(35-32) |The EventID which is currently being matched. |TBD |- |0x2003 |R |Current EventID(31-16) | |TBD |- |0x2004 |R |Current EventID(15- 0) | |TBD |- |0x2005 |R |Newest EventID(35-32) |The EventID most recently received from the TTC system. |TBD |- |0x2006 |R |Newest EventID(31-16) | |TBD |- |0x2007 |R |Newest EventID(15- 0) | |TBD |- |0x2008 |RW |L0 trigger timeout |Number of clock cycles 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |TBD |- |0x2009 |RW |FEE buffers available |Config: Holds the number buffers assumed on the FEE. |TBD |- |0x200A |RW |Halt FW matching |If LSB is set to 1 the internal FSM will halt in a wait state. |TBD |- |0x200B |w |Force match |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. |TBD |- |0x200C |RW |Re-Request Timeout |Number of clock cycles to wait in between sending requests to the DRORCs. |TBD |- |0x200D |R |Current RequestID |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |TBD |- |0x200E |R |Retry Count |Number of times requests have been sent to DRORCs. |TBD |- |0x2010 |R |Busy time(31-16) |Holds value of counter for number of clock |TBD |- |0x2011 |R |Busy time(15- 0) |cycles BUSY has been asserted. |TBD |- |0x2012 |RW |RX mem filter |Allows filtering of messages that are stored in RX memory. Bit 7-0 is the pattern that will be matched with the channelnumber of the message. Bit 15-8 allows enableing matching of individual bits 7-0. |TBD |- |0x21XX |RW |Channel Registers |'XX' in the address gives the channelnumber in hexadecimal. Bit 0 is enable/disable (0/1) Bit 1 indicates that the current EventID has been matched on this channel. |TBD |} cd86f55cd14fd0a09273c84b1120638bb1382f66 844 843 2009-10-20T15:06:12Z St09909 38 moved [[Busy Box and related/BusyBoxRegisters]] to [[Busy Box and related/BusyBox Registers]] wikitext text/x-wiki {| border="1" cellpadding="1" cellspacing="0" |colspan="5"| ====Busy Box Status and Contol Registers==== |- !Address !Read/Write !Name !Description !Default Value |- |0x0001 |RW |TX module |For sending messages to DRORCs. Bit 7-0 is TX data. Bit 15-8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |TBD |- |0x1XXX |RW |RX memory |Memory where all messages received from DRORCs will be stored. |TBD |- |0x2000 |R |RX memory pointer |Holds the value where the next message will be written in RX memory. |TBD |- |0x2001 |R |EventID count |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |TBD |- |0x2002 |R |Current EventID(35-32) |The EventID which is currently being matched. |TBD |- |0x2003 |R |Current EventID(31-16) | |TBD |- |0x2004 |R |Current EventID(15- 0) | |TBD |- |0x2005 |R |Newest EventID(35-32) |The EventID most recently received from the TTC system. |TBD |- |0x2006 |R |Newest EventID(31-16) | |TBD |- |0x2007 |R |Newest EventID(15- 0) | |TBD |- |0x2008 |RW |L0 trigger timeout |Number of clock cycles 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |TBD |- |0x2009 |RW |FEE buffers available |Config: Holds the number buffers assumed on the FEE. |TBD |- |0x200A |RW |Halt FW matching |If LSB is set to 1 the internal FSM will halt in a wait state. |TBD |- |0x200B |w |Force match |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. |TBD |- |0x200C |RW |Re-Request Timeout |Number of clock cycles to wait in between sending requests to the DRORCs. |TBD |- |0x200D |R |Current RequestID |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |TBD |- |0x200E |R |Retry Count |Number of times requests have been sent to DRORCs. |TBD |- |0x2010 |R |Busy time(31-16) |Holds value of counter for number of clock |TBD |- |0x2011 |R |Busy time(15- 0) |cycles BUSY has been asserted. |TBD |- |0x2012 |RW |RX mem filter |Allows filtering of messages that are stored in RX memory. Bit 7-0 is the pattern that will be matched with the channelnumber of the message. Bit 15-8 allows enableing matching of individual bits 7-0. |TBD |- |0x21XX |RW |Channel Registers |'XX' in the address gives the channelnumber in hexadecimal. Bit 0 is enable/disable (0/1) Bit 1 indicates that the current EventID has been matched on this channel. |TBD |} cd86f55cd14fd0a09273c84b1120638bb1382f66 849 844 2009-10-21T08:40:40Z St09909 38 wikitext text/x-wiki {| border="1" cellpadding="1" cellspacing="0" |colspan="5"| ====Busy Box Status and Contol Registers==== |- !Address !Mode !width="170"|Name !Description !Default Value |- |0x0001 |RW |TX module |For sending messages to DRORCs. * Bit 7-0 is TX data. * Bit 15-8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |0x1XXX |RW |RX memory |Memory where all messages received from DRORCs will be stored. |0x0000 |- |0x2000 |R |RX memory pointer |Holds the value where the next message will be written in RX memory. |0x0000 |- |0x2001 |R |EventID FIFO count |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |0x2002 |R |Current EventID(35-32) |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |0x2003 |R |Current EventID(31-16) |0x0000 |- |0x2004 |R |Current EventID(15- 0) |0x0000 |- |0x2005 |R |Newest EventID(35-32) |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |0x2006 |R |Newest EventID(31-16) |0x0000 |- |0x2007 |R |Newest EventID(15- 0) |0x0000 |- |0x2008 |RW |L0 Trigger Timeout |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |0x2009 |RW |Busy Condition |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 7-4 - Current MEB count. * Bit 3-0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |0x200A |RW |Halt FSM matching |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |0x200B |T |Force match |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |0x200C |RW |Re-Request Timeout |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |0x200D |R |Current RequestID |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |0x200E |R |Retry Count(15-0) |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |0x2010 |R |Busy time(31-16) |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |0x2011 |R |Busy time(15-0) |0x0000 |- |0x2012 |RW |RX mem filter |Allows filtering of messages that are stored in RX memory. *Bit 7-0 is the pattern that will be matched with the channelnumber of the message. *Bit 15-8 allows enableing matching of individual bits 7-0. |0x0000 |- |0x2015 |R |Firmware Revision |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |0x2016 |RW |Stresstest Enable(0) |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |0x21XX |RW |Channel Registers |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |} 0cd7d874f11a256affdba083c9c49d129f8b49c2 850 849 2009-10-21T09:06:20Z St09909 38 /* Busy Box Status and Contol Registers */ wikitext text/x-wiki {| border="1" cellpadding="1" cellspacing="0" |colspan="5"| {| border="1" cellpadding="1" cellspacing="0" |colspan="5"| ====Busy Box Status and Contol Registers==== |- !Address !Mode !width="170"|Name !Description !Default Value |- |0x0001 |RW |TX module(15:0) |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |0x1000-0x1FFF |RW |RX memory |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - DRORC Message(47:32) * Address ending "01" - DRORC Message(31:16) * Address ending "10" - DRORC Message(15:0) * Address ending "11" - Receiving Channel number(7:0) |0x0000 |- |0x2000 |R |RX memory pointer(13:0) |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |0x2001 |R |EventID FIFO count(3:0) |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |0x2002 |R |Current EventID(35:32) |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |0x2003 |R |Current EventID(31:16) |0x0000 |- |0x2004 |R |Current EventID(15:0) |0x0000 |- |0x2005 |R |Newest EventID(35:32) |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |0x2006 |R |Newest EventID(31:16) |0x0000 |- |0x2007 |R |Newest EventID(15:0) |0x0000 |- |0x2008 |RW |L0 Trigger Timeout(15:0) |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |0x2009 |RW |Busy Condition(15:0) |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |0x200A |RW |Halt FSM matching(0) |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |0x200B |T |Force match(0) |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |0x200C |RW |Re-Request Timeout(15:0) |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |0x200D |R |Current RequestID(3:0) |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |0x200E |R |Retry Count(15:0) |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |0x2010 |R |Busy time(31:16) |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |0x2011 |R |Busy time(15:0) |0x0000 |- |0x2012 |RW |RX mem filter(15:0) |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |0x2014 |R |Number of Channels |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |0x2015 |R |Firmware Revision |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |0x2016 |RW |Stresstest Enable(0) |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |0x21XX |RW |Channel Registers |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |} cf0ea19120b42f6641c737073b83b4e365becad3 851 850 2009-10-21T10:12:34Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - DRORC Message(47:32) * Address ending "01" - DRORC Message(31:16) * Address ending "10" - DRORC Message(15:0) * Address ending "11" - Receiving Channel number(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- !colspan="5"| Trigger Receiver Module Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |rowspan="11" |Control(15:0) |rowspan="11" |0x3000 |RW |[0] Serial B on/off |1 |- |RW |[1] Disable error masking |0 |- |RW |[2] Enable RoI Decoding |0 |- |RW |[3] L0 Support |1 |- |R |[4:7] Unused |N/A |- |RW |[8] L2Accept Event FIFO storage mask |1 |- |RW |[9] L2Reject Event FIFO storage mask |1 |- |RW |[10] L2Timeout Event FIFO storage mask |1 |- |RW |[11] L1message mask |1 |- |RW |[12] Trigger Input Mask Enable |0 |- |RW |[13:15] Unused |N/A |- |rowspan="6" |Control(7:0) |rowspan="6" |0x3001 |R |[0] Bunschcounter overflow |N/A |- |R |[1] Run Active |N/A |- |R |[2] Busy receiving trigger sequence |N/A |- |R |[3] Unused |N/A |- |R |[7:4] CDH version |0x2 |- |R |[15:8] Trigger Receiver version |0x13 |- |Reset Counters |0x3002 |T |[0] Reset all counters in the Trigger Receiver |N/A |- - |} 562e8cd6f621f36fc5d4f501771ba25dffd17d36 853 851 2009-10-22T08:29:11Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - DRORC Message(47:32) * Address ending "01" - DRORC Message(31:16) * Address ending "10" - DRORC Message(15:0) * Address ending "11" - Receiving Channel number(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |rowspan="11" |Control(15:0) |rowspan="11" |0x3000 |RW |[0] Serial B on/off |1 |- |RW |[1] Disable error masking |0 |- |RW |[2] Enable RoI Decoding |0 |- |RW |[3] L0 Support |1 |- |R |[4:7] Unused |N/A |- |RW |[8] L2Accept Event FIFO storage mask |1 |- |RW |[9] L2Reject Event FIFO storage mask |1 |- |RW |[10] L2Timeout Event FIFO storage mask |1 |- |RW |[11] L1message mask |1 |- |RW |[12] Trigger Input Mask Enable |0 |- |RW |[13:15] Unused |N/A |- |rowspan="6" |Control(7:0) |rowspan="6" |0x3001 |R |[0] Bunschcounter overflow |N/A |- |R |[1] Run Active |N/A |- |R |[2] Busy receiving trigger sequence |N/A |- |R |[3] Unused |N/A |- |R |[7:4] CDH version |0x2 |- |R |[15:8] Trigger Receiver version |0x13 |- |Reset Counters |0x3002 |T |[0] Reset all counters in the Trigger Receiver |N/A |- |} 4acd43fa8866f694af5df73d4468657c9a8224d9 854 853 2009-10-22T11:41:25Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - DRORC Message(47:32) * Address ending "01" - DRORC Message(31:16) * Address ending "10" - DRORC Message(15:0) * Address ending "11" - Receiving Channel number(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="120"|Bit slice !Description |---- |Control |0x3000 |RW |[15:13] |Unused |---- | | | |[12] |Trigger Input Mask Enable. Default=0 |---- | | | |[11] |L1a message mask. Default=1 |---- | | | |[10] |L2 Timeout FIFO storage mask. Default=1 |---- | | | |[9] |L2r FIFO storage mask. Default=1 |---- | | | |[8] |L2a FIFO storage mask. Default=1 |---- | | | |[7:4] |Unused |---- | | | |[3] |L0 support. Default=1 |---- | | | |[2] |Enable RoI decoding. Default=0 |---- | | | |[1] |Disable_error_masking. Default=0 |---- | | | |[0] |Serial B channel on/off. Default=1 |---- |Control |0x3001 | |[15:8] |Trigger Receiver Version. Default=0x13 |---- | | | |[7:4] |CDH version. Default=0x2 |---- | | | |[3] |Not Used |---- | | | |[2] |Busy (receiving sequence) - |---- | | | |[1] |Run Active - |---- | | | |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |L1_Latency |0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- | | |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info[17:0] |0x4028 |R |[12:0] |Latest Received Event information: |---- | | |R |[12] |Include payload |---- | | |R |[11] |Event has L2 Accept trigger |---- | | |R |[10] |Event has L2 Reject trigger |---- | | |R |[9] |Calibration trigger event |---- | | |R |[8] |Software trigger event |---- | | |R |[4:7] |Calibration/SW trigger type (= RoC) |---- | | |R |[3] |NA(=‘0’) |---- | | |R |[2] |NA(=‘0’) |---- | | |R |[1] |Region of Interest announced (=ESR) |---- | | |R |[0] |NA(=’0’) |---- |Event_error |0x4029 |R |[15:0] |Latest Received Event error conditions: |---- | | |R |[15] |L1 message arrives outside legal timeslot |---- | | |R |[14] |Missing L1 |---- | | |R |[13] |Boundary L1 |---- | | |R |[12] |Spurious L1 |---- | | |R |[11] |Missing L0 |---- | | |R |[10] |Spurious L0 |---- | | |R |[9] |TTCrx Address Error (not X”0003”) |---- | | |R |[8] |NA (= ‘0’) |---- | | |R |[7] |Incomplete L2a Message |---- | | |R |[6] |Incomplete L1 Message |---- | | |R |[5] |Unknown Message Address Received |---- | | |R |[4] |Double Bit Hamming Error Broadcast. |---- | | |R |[3] |Single Bit Hamming Error Broadcast. |---- | | |R |[2] |Double Bit Hamming Error Individually Addr. |---- | | |R |[1] |Single Bit Hamming Error Individually Addr. |---- | | |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x4029 |R |[8:0] |Latest Received Event error conditions: |---- | | |R |[8] |NA (= ‘0’) |---- | | |R |[7] |L2 message content error |---- | | |R |[6] |L1 message content error |---- | | |R |[5] |Prepulse error (=0; possible future use) |---- | | |R |[4] |NA (= ‘0’) |---- | | |R |[3] |NA (= ‘0’) |---- | | |R |[2] |L2 message missing/timeout |---- | | |R |[1] |L2 message arrives outside legal timeslot |---- | | |R |[0] |L1 message missing/timeout |---- |} 601b6e680bd072b6123145e77fc3487d1191bdf2 855 854 2009-10-22T12:17:48Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - DRORC Message(47:32) * Address ending "01" - DRORC Message(31:16) * Address ending "10" - DRORC Message(15:0) * Address ending "11" - Receiving Channel number(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x4051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x4053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x4054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 7d63de13fb08ff681365033bf9159d5a25010844 0 243 845 2009-10-20T15:06:12Z St09909 38 moved [[Busy Box and related/BusyBoxRegisters]] to [[Busy Box and related/BusyBox Registers]] wikitext text/x-wiki #REDIRECT [[Busy Box and related/BusyBox Registers]] 9540d053f1fa0b3a5c7a9edea277cd9bc9793a5c 0 28 859 78 2009-10-29T19:02:24Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg New Library og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "View Type" Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg show palette fra ikonlisten til høyre. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation a45724bceaeaa5208fe8403e36984f9382cb246c 860 859 2009-10-29T19:06:36Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg show palette fra ikonlisten til høyre. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 1b318062c8f7c0ff90fcd44f2f854f66d0fd8148 861 860 2009-10-29T20:06:59Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 20b5906717a6ab4c1ecd79031065a425fa003312 862 861 2009-10-29T20:25:21Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 4cfe683fb6c0a73a4057cefe9709332f84bcdf61 864 862 2009-11-02T09:47:26Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4_new.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menuen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må fortelle simulatoren hva vi vil ha ut av den. Sett prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 5ca5aa5daea49fe9079b71721f72cf5a8b957c0a 0 244 869 2009-11-02T15:15:35Z Tbu082 19 Created page with 'November 4, IFT Room 316, 14:00 Speakers: * Dominik Fehlker * Lars-Halvard Helleve * Kristine Indahl Helle' wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * Dominik Fehlker * Lars-Halvard Helleve * Kristine Indahl Helle 64f4c7edc4de4341b9ce515ba702ac39d1fbd1c6 870 869 2009-11-02T15:16:41Z Tbu082 19 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * Dominik Fehlker * Lars-Halvard Helleve * Kristine Indahl Helle Evo details: e1e941b3553e194c80da9494b5aac86e89263bbd 871 870 2009-11-02T16:03:04Z Mug004 27 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * Dominik Fehlker * Lars-Halvard Helleve * Kristine Indahl Helle Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) 7669e2964fc7cacb912298eb9a06c6cf68855f39 0 244 875 871 2009-11-04T12:13:02Z Dfe002 7 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt Dominik Fehlker] * Lars-Halvard Helleve * Kristine Indahl Helle Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) c49873a6932308d5d1147dfedc63c6261c05c965 877 875 2009-11-04T12:15:50Z Tbu082 19 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt Dominik Fehlker] * Lars-Halvard Helleve * Kristine Indahl Helle - [[File:3D Si pixels]] Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) 6fcb4a2e6591eb6dd5bdf1855ecb11a79b34aa0b 878 877 2009-11-04T12:16:29Z Lhe014 14 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt Dominik Fehlker] * [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf Lars-Halvard Thunold Helleve] * Kristine Indahl Helle - [[File:3D Si pixels]] Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) f7928ce1c7289fdd3b28e454a269f4b291c29ffc 880 878 2009-11-04T12:18:16Z Tbu082 19 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt Dominik Fehlker] * [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf Lars-Halvard Thunold Helleve] * Kristine Indahl Helle - [[File:3D_Si_pixels.pdf|3D Si Pixels]] Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) c53280aebf51ee93aa22dcf2310e5058c11bc132 881 880 2009-11-04T12:18:28Z Tbu082 19 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt Dominik Fehlker] * [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf Lars-Halvard Thunold Helleve] * Kristine Indahl Helle - [[File:3D_Si_pixels.pdf]] Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) d8741b0ca1de4bd9bbbc58bc93c0397e7bd30367 882 881 2009-11-04T12:33:51Z Tbu082 19 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt Dominik Fehlker] [[File:Dominik_Fehlker_part_phys_seminar_041109.pdf]] * [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf Lars-Halvard Thunold Helleve] * Kristine Indahl Helle - [[File:3D_Si_pixels.pdf]] Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) 821c49acd3c5ca02a6ad2f88582dbfba99ef2a3f 884 882 2009-11-04T12:41:59Z Dfe002 7 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * Dominik Fehlker [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf Lars-Halvard Thunold Helleve] * Kristine Indahl Helle - [[File:3D_Si_pixels.pdf]] Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) d82f6ee0c0d2fc72cf8b27f97e6e71c1fa2d41bf 6 245 876 2009-11-04T12:15:24Z Lhe014 14 SiPM small talk by Lars-Halvard Thunold Helleve wikitext text/x-wiki SiPM small talk by Lars-Halvard Thunold Helleve bccd7390194a998d199675e9f488e9c0c16f49cf 6 246 879 2009-11-04T12:17:35Z Tbu082 19 Kristine Indahl Helles presentation for IFT particle physics seminar 2009-11-04 wikitext text/x-wiki Kristine Indahl Helles presentation for IFT particle physics seminar 2009-11-04 932247c918e935e65d48fa54a920b68f0c361ba7 6 247 883 2009-11-04T12:34:30Z Tbu082 19 Dominik Fehlker - Particle Physics Seminar 2009-11-04 wikitext text/x-wiki Dominik Fehlker - Particle Physics Seminar 2009-11-04 8ab30f3fd9567a6b168688ab8fe2761226edfd59 0 212 885 714 2009-11-05T08:14:35Z Dfe002 7 wikitext text/x-wiki 15.09.09 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.09 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] 3.2.2009 * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results] f8c48584b256297212dbc9dce12e191bc217c5ac 887 885 2009-11-05T08:15:04Z Dfe002 7 wikitext text/x-wiki 15.09.2009 *[https://wikihost.uib.no/ift/images/c/ce/PET-presentasjon-Detectorlab_english.pdf Jostein: PET presentation] 24.06.2009 *[https://wikihost.uib.no/ift/images/d/d6/Hege_Masterpresentation.pdf Hege: Masterpresentation] 03.02.2009 * [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/axialpet.ppt Dominik: MAPD/MPPC Characterization & Axial PET] * [https://wikihost.uib.no/ift/images/9/90/Linearity_030209.pdf Hege: Linearity Results] 056e511ef46eb3edee6e5ffae3c52ac0cf63ff2c 0 21 886 874 2009-11-05T08:14:39Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [http://https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab * Our weekly labmeeting is Tuesdays 11:15 in room 332. == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Upcoming meetings and conferences== * 11.12.09: MedViz seminar series - presentation of PET related projects, 1 hour * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 02.01. - 08.01.10: Spåtind meeting on particle physics (http://indico.cern.ch/event/spaatind-2010) * 15.02. - 20.02.10: Vienna conference on Instrumentation - Deadline 16.11.09. (http://vci.hephy.at/2010/) * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany === For internal use === [[material]] that can be used in official presentations. 824cbdc115fbcb9a8df523ede4256f00628ea619 910 886 2009-11-18T08:20:37Z Nfyku 4 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * Our weekly labmeeting is Tuesdays 11:15 in room 332. * 11.12.09: MedViz seminar series - presentation of PET related projects, 1 hour * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 02.01. - 08.01.10: Spåtind meeting on particle physics (http://indico.cern.ch/event/spaatind-2010) * 15.02. - 20.02.10: Vienna conference on Instrumentation - Deadline 16.11.09. (http://vci.hephy.at/2010/) * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany === For internal use === [[material]] that can be used in official presentations. c47793373ca2e34a271d272be6ee22ddceb5e1d1 0 28 889 864 2009-11-05T12:08:12Z Nfyku 4 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Kilder (spenning-, strøm- og signalkilder) finnes under Add Source i menyen til høyre. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. Velg f. eks. en sinusspenning med frekvens på 1000Hz og amplitude 1V. Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint" fra menyen til høyre. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Sjekk at SPICE_Netlister er valgt. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet. Velg Probes/Plots og velg f. eks. TRAN for transient. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation ce38f7cd2a6eb784caf4148f176a01041e8d24fb 896 889 2009-11-16T18:40:40Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Denne informasjonen kan du finne igjen i .chi-filen. Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 52bd5f8c54b453c317496a5a240c34efc5ae8b66 897 896 2009-11-16T19:48:02Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. EZwave kan også startes fra kommandolinjen <pre> ezwave </pre> Åpne filen med etternavn .wdb i viewpoint-katalogen. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation b830b7c8c1979660484861a7f92d7a9cb59c8aa6 898 897 2009-11-16T19:49:18Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation 596a82ba7457715adab5a354d1b5c9dc8ffdd5ae 900 898 2009-11-16T20:04:24Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation adb9eef121341783839851f2f044038e1ffff056 901 900 2009-11-16T20:40:10Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-G (stor G) så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation d47df2413148d7d57c35e3149bada1cc5b775de7 902 901 2009-11-16T20:43:52Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation a722ea8e38e0634f57b8a5f38d5986637846c5cf 903 902 2009-11-17T08:43:23Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[Starte opp IC studio]] og fått startet programmet. ==Konstruksjon av inverter== 98256b8f330ebc7669fc2b23b70cacd7c40ce4c3 904 903 2009-11-17T08:44:12Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", http://doc.uib.no/wiki/ICStation = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 41531830cc079b877ea06e770e852961f21d3bac 905 904 2009-11-17T09:01:04Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til transistorene som under. Transistorene finner du under "Devices->MOS->nmos4" for nmos og "Devices->MOS->pmos4" for pmos. 6. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 7. Legg til 2bee0f7df59ae68f7808c78d295595b64b029bf3 906 905 2009-11-17T09:08:20Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til 748658bda42ca901a6263dabba725dd7ee0ed413 907 906 2009-11-17T09:10:43Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/mgc/ic.2005.1/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> For 2008 versjonen finner du dokumentasjonen under /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/ for pdf filene og /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ for html filene. Pdf filene kan åpnes med <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i et terminalvindu. Før du lukker dette kan det være lurt å bla litt her for å se etter feilmeldinger. Dersom du satte på DCOP under analyse vil du litt lengre oppe i filen finne alle nodespenningene og total power consumption for kretsen. Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuellt,erller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout" 8b6d407d07bbe03cdf2fc7fc52052be0ca29b914 909 907 2009-11-18T08:11:38Z Nfyku 4 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout" aee44c496bdaab47257a3971d98cd60feed28c50 911 909 2009-11-18T09:39:03Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[inverter.jpg]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk på Q og A teksten og trykk delete. Trykk så på "hide labels" på vesntre side. [[symbol.jpg]] 13. e3c2c7864d54fa297f19db5fb66ca8a5007f3e4b 912 911 2009-11-18T10:56:06Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[inverter.jpg]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk på Q og A teksten og trykk delete. Trykk så på "hide labels" på venstre side. [[symbol.jpg]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[pulse.jpg]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 5n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 3dd40f1928d2d97a260d4f220327657dd0e20e61 913 912 2009-11-18T11:27:40Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for delay estimering = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. ==Konstruksjon av inverter== 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[inverter.jpg]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[symbol.jpg]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[pulse.jpg]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. 3c434349718450db7f768cc90cc32656302e0930 917 913 2009-11-18T16:54:45Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[inverter.jpg]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[symbol.jpg]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. 437dd14dad8209405eb97ac8127649e5e0f6ef6a 926 917 2009-11-18T18:00:02Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|600px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|300px]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[inverter.jpg]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[symbol.jpg]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. ec061d6ed1bb3bc1a75b4977292072906e756eb4 927 926 2009-11-18T18:00:47Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[inverter.jpg]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[symbol.jpg]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. c5f14dc4ba5a39eb87b0fe7306d59227be9b79e0 928 927 2009-11-18T18:14:43Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|400px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. 465150654540ce91f5642c67eba0ba4b451dbf63 0 242 890 855 2009-11-09T09:00:10Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - DRORC Message(47:32) * Address ending "01" - DRORC Message(31:16) * Address ending "10" - DRORC Message(15:0) * Address ending "11" - Receiving Channel number(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 8e7d6153e05e9f6ad6b571ac237ae722c58fb27d 0 111 895 819 2009-11-13T08:10:02Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 |Optics department |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | |2x Anja |- |TTi EL302D |30V, 2A dual linear DC power supply | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} bbbf6b498245624920779c76a618fe8a39ea8404 6 248 899 2009-11-16T19:49:52Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 223 914 757 2009-11-18T16:51:29Z Ave082 33 wikitext text/x-wiki == Øvingsoppgaver PHYS223== === Problem 3.4 from Gray et.al. === For the common-source amplifier of Fig 3.12, calculate the small-signal voltage gain and the bias values of Vi and Vo where the small-signal voltage gain is unity with the transistor operating in the active region. [[Spice deck]] == Øvingsoppgaver PHYS222== === Estimering av delay === Du skal i denne oppgaven konstruere en inverter av transistorer, lage symbol på den for så å finne propogation delayet ved hjelp av simulering. Du skal også finne delayet for en Fan Out of Four FO4, en statisk flipflop og en dynamisk flipflop. 1. Følg tutorialet [[her]] eller prøv deg frem selv for å lage en inverter med tilhørende symbol i ICstudio. 2. Lag et nytt skjema der du legger inn inverteren, signal kildene og slikt, bruk en inverter som last. 3. Simuler og finn tpdr og tpdf 4. Lag til en inverter til under som har fire parallelle invertere som last 5. Simuler og finn tpdr og tpdf 6. Lag en dynamisk flipflop som vist i figur 7.19a s405 i Weste et.al. 7. Simuler og finn tpdr og tpdf om du vil kan du og prøve å finne ut setup tiden ved å sende innsagnelet inn litt før klokken. Du vil kunne se at utsignalet blir liggende på et mellomnivå i en del av pulsen. 8. Lag en latch fra transistorer med tilhørende symbol. Se figur 7.18 s405 i Weste et.al. 9. Gjør 6. og 7. for en statisk flipflop med det nye symbolet. Se figur 7.19b s405 i Weste et.al. 10. Regn ut path delay for den dynamiske og statisk flipflopen, bruk unit kapasitanser. 11. Prøv å bruke kondensatorene oppgitt av simuleringen for å se om du får samme delay som simuleringen. [[Tips]] [[Category:Mikroelektronikk]] d39e8fce9e14f6802e68b7e1d6f0fec812fd4aa6 915 914 2009-11-18T16:52:44Z Ave082 33 wikitext text/x-wiki == Øvingsoppgaver PHYS223== === Problem 3.4 from Gray et.al. === For the common-source amplifier of Fig 3.12, calculate the small-signal voltage gain and the bias values of Vi and Vo where the small-signal voltage gain is unity with the transistor operating in the active region. [[Spice deck]] == Øvingsoppgaver PHYS222== === Estimering av delay === Du skal i denne oppgaven konstruere en inverter av transistorer, lage symbol på den for så å finne propogation delayet ved hjelp av simulering. Du skal også finne delayet for en Fan Out of Four FO4, en statisk flipflop og en dynamisk flipflop. 1. Følg tutorialet [[her]] eller prøv deg frem selv for å lage en inverter med tilhørende symbol i ICstudio. 2. Lag et nytt skjema der du legger inn inverteren, signal kildene og slikt, bruk en inverter som last. 3. Simuler og finn tpdr og tpdf 4. Lag til en inverter til under som har fire parallelle invertere som last 5. Simuler og finn tpdr og tpdf 6. Lag en dynamisk flipflop som vist i figur 7.19a s405 i Weste et.al. 7. Simuler og finn tpdr og tpdf om du vil kan du og prøve å finne ut setup tiden ved å sende innsagnelet inn litt før klokken. Du vil kunne se at utsignalet blir liggende på et mellomnivå i en del av pulsen. 8. Lag en latch fra transistorer med tilhørende symbol. Se figur 7.18 s405 i Weste et.al. 9. Gjør 6. og 7. for en statisk flipflop med det nye symbolet. Se figur 7.19b s405 i Weste et.al. 10. Regn ut path delay for den dynamiske og statisk flipflopen, bruk unit kapasitanser. 11. Prøv å bruke kondensatorene oppgitt av simuleringen for å se om du får samme delay som simuleringen. [[Tips]] [[Category:Mikroelektronikk]] 9bde266dfbf1eff26b25c148c1ef129c735a36a2 918 915 2009-11-18T16:55:31Z Ave082 33 wikitext text/x-wiki == Øvingsoppgaver PHYS223== === Problem 3.4 from Gray et.al. === For the common-source amplifier of Fig 3.12, calculate the small-signal voltage gain and the bias values of Vi and Vo where the small-signal voltage gain is unity with the transistor operating in the active region. [[Spice deck]] == Øvingsoppgaver PHYS222== === Estimering av delay === Du skal i denne oppgaven konstruere en inverter av transistorer, lage symbol på den for så å finne propogation delayet ved hjelp av simulering. Du skal også finne delayet for en Fan Out of Four FO4, en statisk flipflop og en dynamisk flipflop. 1. Følg tutorialet [[IC_studio#Tutorial_for_konstruksjon_av_inverter_og_symbol]] eller prøv deg frem selv for å lage en inverter med tilhørende symbol i ICstudio. 2. Lag et nytt skjema der du legger inn inverteren, signal kildene og slikt, bruk en inverter som last. 3. Simuler og finn tpdr og tpdf 4. Lag til en inverter til under som har fire parallelle invertere som last 5. Simuler og finn tpdr og tpdf 6. Lag en dynamisk flipflop som vist i figur 7.19a s405 i Weste et.al. 7. Simuler og finn tpdr og tpdf om du vil kan du og prøve å finne ut setup tiden ved å sende innsagnelet inn litt før klokken. Du vil kunne se at utsignalet blir liggende på et mellomnivå i en del av pulsen. 8. Lag en latch fra transistorer med tilhørende symbol. Se figur 7.18 s405 i Weste et.al. 9. Gjør 6. og 7. for en statisk flipflop med det nye symbolet. Se figur 7.19b s405 i Weste et.al. 10. Regn ut path delay for den dynamiske og statisk flipflopen, bruk unit kapasitanser. 11. Prøv å bruke kondensatorene oppgitt av simuleringen for å se om du får samme delay som simuleringen. [[Tips]] [[Category:Mikroelektronikk]] a8fd944863fb5935ac1fc1af0aac83c5c38881c7 0 249 916 2009-11-18T16:53:52Z Ave082 33 Created page with '==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og t...' wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[pulse.jpg]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. fa5443a684b31b2a7e2dfe023fd2ea16f57b541c 921 916 2009-11-18T17:56:14Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[pulse.jpg]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[skjema.jpg]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[graf.jpg]] 0773584f9c0e5062c4fe0897c01cc8bc4a64488d 922 921 2009-11-18T17:57:07Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] 0b5cfd3d4c7a7006bb86c847f07360be59495202 924 922 2009-11-18T17:58:37Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg|200px]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] 167c88a3d4cc5dda9c7f7078231a44f5c10b47b1 925 924 2009-11-18T17:58:57Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg|400px]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] 00b8feda2a3b47c4d963eebe3c829b39e6342d02 0 105 919 217 2009-11-18T17:20:33Z Ave082 33 wikitext text/x-wiki [[http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow]] [[http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial]] [[http://pages.cs.wisc.edu/~david/courses/cs755/cs755/ VLSI System Design course with tutorials]] [[http://www.swarthmore.edu/NatSci/tali/E77/Mentor_Tutorials/tutorials.htm Mentor Graphic Tutorials]] [[Category:Mikroelektronikk]] 3d90533cc11db45e1ae71d1c2e735d561c73e53f 920 919 2009-11-18T17:54:32Z Ave082 33 wikitext text/x-wiki [http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow] [http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial] [http://pages.cs.wisc.edu/~david/courses/cs755/cs755/ VLSI System Design course with tutorials] [http://www.swarthmore.edu/NatSci/tali/E77/Mentor_Tutorials/tutorials.htm Mentor Graphic Tutorials] [[Category:Mikroelektronikk]] 7719b95981516ca1e89234137f08790765d8fb32 6 250 923 2009-11-18T17:57:39Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 251 929 2009-11-18T18:15:04Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 252 930 2009-11-18T18:15:33Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 28 931 928 2009-11-18T18:16:13Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|300px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. c9aecbcaa3f6284e3569677fd23251b16a87fc14 932 931 2009-11-18T18:16:52Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. 01b9440f72ae9aed1de3c2594bd480151de0db8a 936 932 2009-11-18T18:34:01Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". 269c42c203beea0880a39e0dc6ccdc408af89aef 937 936 2009-11-18T18:57:04Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". 83bcf94817db43fbb82f6764750d4f5f95510692 938 937 2009-11-18T18:59:17Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/<math>\sqrt(Hz)</math> Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". 484883da6f24f48f37a822bfe5de0f2e17e04489 939 938 2009-11-18T19:00:19Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". 762fdc5228ab0f8aad68bd33385a82363fa84336 6 253 933 2009-11-18T18:17:45Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 254 934 2009-11-18T18:19:10Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 249 935 925 2009-11-18T18:20:04Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg|400px]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg|600px]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] ef9d2de25fbcf1ed7415caef00460ebd1e55eeda 940 935 2009-11-18T19:44:53Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg|400px]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg|600px]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] == Andre tips til oppgaven == Fungerer ikke dynamiske eller statiske vippen? Sjekk at du har plassert clock og clock invers på riktig inngang/riktig transistor, de skifter side fra første til andre ledd. Prøv å bruke Cgs til kalkulering av delay om du ikke får noe fornuftig svar. Når du skal lage clk invers så ikke bruk en inverter, lag to pulskilder der den ene har et delay like langt som en pulsbredde. Ellers så får du et ekstra delay på klokken. a12abad3deeab121329305d48b70a543a0fb0f3f 941 940 2009-11-18T19:51:38Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg|400px]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg|600px]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] == Andre tips til oppgaven == Fungerer ikke dynamiske eller statiske vippen? Sjekk at du har plassert clock og clock invers på riktig inngang/riktig transistor, de skifter side fra første til andre ledd. Prøv å bruke Cgs til kalkulering av delay om du ikke får noe fornuftig svar. Når du skal lage clk invers så ikke bruk en inverter, lag to pulskilder der den ene har et delay like langt som en pulsbredde. Ellers så får du et ekstra delay på klokken. Tristate bufferet kan regnes som parasitisk, mao tilfører den 8C på inngangen og utgangen. bf7bf31758f2a35c2f8967b2bd0afa72ef42d55f 942 941 2009-11-18T21:08:29Z Ave082 33 wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg|400px]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg|600px]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] == Andre tips til oppgaven == Fungerer ikke dynamiske eller statiske vippen? Sjekk at du har plassert clock og clock invers på riktig inngang/riktig transistor, de skifter side fra første til andre ledd. Prøv å bruke Cgs til kalkulering av delay om du ikke får noe fornuftig svar. Når du skal lage clk invers så er det en fordel å ikke bruke en inverter, lag to pulskilder der den ene har et delay like langt som en pulsbredde, ellers så får du et ekstra delay på klokken aka clock skew. Tristate bufferet kan regnes som parasitisk, mao tilfører den 8C på inngangen og utgangen. Transmition gaten kobles opp med source mot kilden. Kobl bulk for nmos til gnd og pmos til VDD. Blir utsignalet bare bølgete rundt VDD så har du for kort pulslengde, hold deg over 2ns. 2ca21f77ce9330696efa7bdadb33b8ac7f1dc78d 0 242 943 890 2009-11-19T14:12:32Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} b8d7f90a2351792c35d412e58389ecef978c2e92 965 943 2009-11-25T15:22:52Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} da055be7c316afa2fada69162c49b56e60f99402 966 965 2009-11-25T15:24:54Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 34 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 996a0095ac814cef4a748057e74ee505eb18312c 967 966 2009-11-25T15:25:58Z St09909 38 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 40 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} b04d88f4e7b94713ea9debe169cd5eb3e1aba1ea 0 139 944 868 2009-11-24T10:53:10Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[November 24 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 81974aaabda5bd5ca24ca422eac685ef5378d02d 945 944 2009-11-24T10:56:17Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 1cee97514e97a56efb5ab2258f0b9211315d367c 0 255 946 2009-11-24T10:56:23Z Tbu082 19 Created page with 'Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - <math>B_s\rightarrow\mu\mu</math> * Jørn Maland - Black Holes Evo details: * Community: Universe * Name: Bergen gr...' wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - <math>B_s\rightarrow\mu\mu</math> * Jørn Maland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle 3916159d952c055caa4b926a2b2352f8ae57b730 947 946 2009-11-24T10:56:44Z Tbu082 19 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Bs->mu,mu * Jørn Maland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle 6cfac32e4fb391302a5eafc8ef6150e496139a31 948 947 2009-11-24T11:00:18Z Tbu082 19 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Bs->mu,mu * Jørn Maland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle [[ParticlePhysicsGroupMeetings|Back to meetings page]] 8696eca2eac724582857052bee53bfc957abdc96 950 948 2009-11-24T11:00:49Z Tbu082 19 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Bs->mu,mu * Jørn Maland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] 27f6d06e574ddeb6e4e4da659cb97825064b9efd 951 950 2009-11-24T12:38:37Z Tbu082 19 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Bs->mu,mu * Jørn Mæland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] b40549be9e4b70a21ef9942593c2dc526171b07a 952 951 2009-11-25T11:13:57Z Mug004 27 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Measurement of BF(Bs->mu,mu) in ATLAS * Jørn Mæland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] ab2b9f27622e237255b2e769b4100e680f45bd72 953 952 2009-11-25T11:17:16Z Mug004 27 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Measurement of BF(Bs->mu,mu) in ATLAS[[File:Bsmumu.pdf]] * Jørn Mæland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] bb100cd3bee25c3dcc99437bbbd2a6b4220a6510 955 953 2009-11-25T11:18:34Z Mug004 27 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Measurement of BF(Bs->mu,mu) in ATLAS [[File:Bsmumu.pdf]] * Jørn Mæland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] 57dc24c199e22bacaa98e28f3b7b6700f91a60ee 956 955 2009-11-25T11:19:31Z Mug004 27 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Measurement of BF(Bs->mu,mu) in ATLAS ([[File:Bsmumu.pdf]]) * Jørn Mæland - Black Holes Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] 73a9e49c3d390b352d6b9db99adf66eee25133a3 958 956 2009-11-25T11:25:09Z Khe002 37 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * Maren Ugland - Measurement of BF(Bs->mu,mu) in ATLAS ([[File:Bsmumu.pdf]]) * Jørn Mæland - Black Holes([[File:BlackholePress.pdf]]) Evo details: * Community: Universe * Name: Bergen group seminar * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] 2c0f869d4c334dfd053214a4fcdea8fe9da70743 0 244 949 884 2009-11-24T11:00:38Z Tbu082 19 wikitext text/x-wiki November 4, IFT Room 316, 14:00 Speakers: * Dominik Fehlker [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf Lars-Halvard Thunold Helleve] * Kristine Indahl Helle - [[File:3D_Si_pixels.pdf]] Evo details: * Community: Universe * Name: Bergen group meeting * Passw: particle (Available from 13:30) [[ParticlePhysicsGroupMeetings|Back to meetings page]] f8990c7c6d4e25b5c7dc88f033aede916130766d 6 258 960 2009-11-25T11:36:09Z Mug004 27 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 963 960 2009-11-25T12:19:57Z Mug004 27 uploaded a new version of "[[File:Bsmumu.pdf]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 964 963 2009-11-25T13:53:22Z Mug004 27 uploaded a new version of "[[File:Bsmumu.pdf]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 260 962 2009-11-25T11:43:26Z Khe002 37 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 234 969 803 2009-11-27T13:42:38Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] 6e11701e46ffffbe616d1e115da75c4914942c0a 974 969 2009-11-27T13:46:56Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] d87eca67fa5f25c860f3a79812436f16354baf0e 975 974 2009-11-27T13:55:15Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Defended November 11th 2009 [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] b6ef94f6a2ea96ee3d76423b5de950cdd41da323 976 975 2009-11-27T13:56:21Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - 11-11-2009 [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - 25-09-2008[[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] 00af045bd3027de1de44f71fcc4c8f4ed48fcae5 977 976 2009-11-27T13:57:10Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - 11-11-2009 [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - 25-09-2008 [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] b3b6c9dbdc24e883fc0fae7ff92b15093b9b3e15 978 977 2009-11-27T13:57:23Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - 11-11-2009 [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - 25-09-2008 [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] 51094b2144013a151acbe86eb679dfec05d97bcd 979 978 2009-11-27T13:58:33Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - 11-11-2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - 25-09-2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - 25-07-2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] a989fc3cb35cf2e6c93a6126e78fd3fbe37d74a3 980 979 2009-11-27T13:59:04Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - 11-11-2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - 25-09-2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - 25-07-2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] d0282af42d73a049648c937f3b2c1c36982da7c5 981 980 2009-11-27T14:00:11Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - [[File:Oyvind_Saetre-Master_Thesis.pdf]] 4546b7e61c238271a472134e3c8bf834b4f86a46 982 981 2009-11-27T14:00:40Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] b491e3f54cd6785753af29228b3074ae018cb767 983 982 2009-11-27T14:05:23Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] === Ongoing Master theses === [[Orjan Dale - Master Thesis]] 2c58668be06e97019ca42b6529423125c93b6bfa 985 983 2009-11-27T14:10:24Z Mug004 27 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] === Ongoing Master theses === [[Orjan Dale - Master Thesis]] 828373827c1626db5dffc3c64e81ddcd0170e713 6 261 970 2009-11-27T13:42:51Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 262 971 2009-11-27T13:43:23Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 263 972 2009-11-27T13:43:47Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 264 973 2009-11-27T13:44:01Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 265 984 2009-11-27T14:10:11Z Tbu082 19 Created page with '==Master Thesis Project Proposal -- Ørjan Dale== === Study of top quark events with tau leptons in ATLAS=== The top quark is the heaviest quark in the Standard Model of partic...' wikitext text/x-wiki ==Master Thesis Project Proposal -- Ørjan Dale== === Study of top quark events with tau leptons in ATLAS=== The top quark is the heaviest quark in the Standard Model of particle physics (SM) with a mass of M_t>170 GeV. It was discovered relatively recently in 1995 at the Tevatron and hence is also the least studied of all quarks. The Large Hadron Collider (LHC) is designed to collide protons at a center of mass of up to 14 TeV and thus will constitute a top factory. Even in the first year of running (2010) top events should be abundant. Events with tops will be characterized by high transverse momentum (p_T), jets with b-quarks (b-jets) and large missing transverse energy (E_T^miss), all of which are also important characteristics of beyond SM physics processes. Thus top quarks studies provide an important early measurement with implications for new physics beyond the SM. One of the most studied extensions to the SM is SUper SYmmetry (SUSY) in which additional super-partners to the SM particles are introduced. SUSY can solve the Hierarchy problem, moreover the Lightest SUSY Particle (LSP) can provide a Dark Matter constituent particle. In SUSY models where the mass difference between of the Neutralino (LSP) and stau (next to LSP) is low co-annihilations balance the production of Dark Matter in the early universe. If such a SUSY model is realized in nature we would expect to see events with large p_T, E_T^miss, b-jets and to two tau leptons in the ATLAS experiment at LHC. The largest background to such a signal would be SM top quark events, where tau leptons arise from W-bosons created in the top decays. Specifically the aim of this work is to analyze tau leptons from top quark events both as SM signal in early LHC data and as background to a possible SUSY signal. The general properties of these events will be examined to be able to identify them correctly, and with this a selection tool will be built. It is to be hoped that the tool can be tested and tuned on real top quarks in early ATLAS data. Finally it will be applied to reject top background in SUSY signal simulations. Broken down by semester the project plan is as follows # Learn relevant ATLAS tools to analyze and present data. Take first look at early ATLAS data. Train and participate in ATLAS data quality monitoring. # Analyze top events in early ATLAS low luminosity data and compare to Monte Carlo simulations. # Make a cut selection for top events in high luminosity data to discriminate between top background and possible SUSY events. Write a selection tool in the ATLAS software framework to implement the cut selection. # Apply the selection to early SUSY analysis. Finish and document the tool. Write thesis. 49b74e85ad6984354812cf954b5195778243498a 0 265 986 984 2009-11-27T14:10:47Z Tbu082 19 wikitext text/x-wiki ==Master Thesis Project Proposal -- Ørjan Dale== === Study of top quark events with tau leptons in ATLAS=== The top quark is the heaviest quark in the Standard Model of particle physics (SM) with a mass of M_t>170 GeV. It was discovered relatively recently in 1995 at the Tevatron and hence is also the least studied of all quarks. The Large Hadron Collider (LHC) is designed to collide protons at a center of mass of up to 14 TeV and thus will constitute a top factory. Even in the first year of running (2010) top events should be abundant. Events with tops will be characterized by high transverse momentum (p_T), jets with b-quarks (b-jets) and large missing transverse energy (E_T^miss), all of which are also important characteristics of beyond SM physics processes. Thus top quarks studies provide an important early measurement with implications for new physics beyond the SM. One of the most studied extensions to the SM is SUper SYmmetry (SUSY) in which additional super-partners to the SM particles are introduced. SUSY can solve the Hierarchy problem, moreover the Lightest SUSY Particle (LSP) can provide a Dark Matter constituent particle. In SUSY models where the mass difference between of the Neutralino (LSP) and stau (next to LSP) is low co-annihilations balance the production of Dark Matter in the early universe. If such a SUSY model is realized in nature we would expect to see events with large p_T, E_T^miss, b-jets and to two tau leptons in the ATLAS experiment at LHC. The largest background to such a signal would be SM top quark events, where tau leptons arise from W-bosons created in the top decays. Specifically the aim of this work is to analyze tau leptons from top quark events both as SM signal in early LHC data and as background to a possible SUSY signal. The general properties of these events will be examined to be able to identify them correctly, and with this a selection tool will be built. It is to be hoped that the tool can be tested and tuned on real top quarks in early ATLAS data. Finally it will be applied to reject top background in SUSY signal simulations. Broken down by semester the project plan is as follows # Learn relevant ATLAS tools to analyze and present data. Take first look at early ATLAS data. Train and participate in ATLAS data quality monitoring. # Analyze top events in early ATLAS low luminosity data and compare to Monte Carlo simulations. # Make a cut selection for top events in high luminosity data to discriminate between top background and possible SUSY events. Write a selection tool in the ATLAS software framework to implement the cut selection. # Apply the selection to early SUSY analysis. Finish and document the tool. Write thesis. [[ATLASThesesNotes|Back to ATLAS Theses and Notes]] 4084d3ac4df5dac8549adf03347931ac1ac7fac1 6 266 987 2009-11-27T14:10:55Z Mug004 27 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 258 988 964 2009-11-27T14:12:13Z Mug004 27 uploaded a new version of "[[File:Bsmumu.pdf]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 234 989 985 2009-11-27T14:58:00Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] === Ongoing Master theses === [[Orjan Dale - Master Thesis]] beb8de4b609081b8a144cd1a3b74c6429d546c79 1026 989 2009-12-12T12:07:55Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-Thesis.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] === Ongoing Master theses === [[Orjan Dale - Master Thesis]] 6eb5bcbbd90952d04dc4800517a436a047093696 1027 1026 2009-12-12T12:08:40Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] === Ongoing Master theses === [[Orjan Dale - Master Thesis]] b8bc528118b55182b341ae989890670384bee7d3 6 267 990 2009-12-02T12:58:51Z Ato061 22 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 268 991 2009-12-02T13:05:03Z Ato061 22 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 139 992 945 2009-12-02T13:07:38Z Ato061 22 wikitext text/x-wiki == Particle Physics Group Meetings == December 02 2009 seminar - Theory [[Media:Mahdi_021209.pdf]] [[Media:Nils-Erik_021209.pdf‎]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 d057b97bd94da7a981ce131c4a5edda368e955ee 993 992 2009-12-02T16:34:09Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == December 02 2009 seminar - Theory [[Media:Mahdi_021209.pdf]] [[Media:Nils-Erik_021209.pdf‎]] * [[December 2 2009 seminare - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 2c820a5582742c21215e6c5b142e492637358e7b 994 993 2009-12-02T16:34:21Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == December 02 2009 seminar - Theory [[Media:Mahdi_021209.pdf]] [[Media:Nils-Erik_021209.pdf‎]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 87115d4235eeae1a63f9ed5e280574f9cf291d65 997 994 2009-12-02T16:36:04Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings == * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 fc9353bd9e9222ecbd19e927efdbb573089f65ac 1000 997 2009-12-08T16:13:49Z Ato061 22 wikitext text/x-wiki == Particle Physics Group Meetings == * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] == Public Skype Chat == Public Skype Chat, connect to skype with this link http://www.skype.com/go/joinpublicchat?chat&skypename=thomas.burgess&topic=NORHEPP+Test&blob=YaJvhGj6eJo_9kzeoBjDMrDaB7dQsyE2Hs-wVrHj6iG6XhbjWxmzdVzEDcBHxTSrMIqe0VzVI8lkv8mQFgjEqjpalLsF2sQNz9qL05kC-T3wEsykVepfIH_cwoXpj3NONJOrNrnnLmdxO6jAQUuvUnIZahKJFZJ8 8c50722770970b00d7ab9f21fed966419bb97800 1037 1000 2010-01-14T15:31:22Z Tbu082 19 wikitext text/x-wiki == Particle Physics Group Meetings/Seminars == * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 90b14dff6203e05ae298ed65ca4dc62cad3e5eaa 1038 1037 2010-01-14T15:37:26Z Tbu082 19 wikitext text/x-wiki Our seminar time is wednesdays at 14:15, usually the seminars are in room 316. == Particle Physics Group Meetings/Seminars == * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] ed0bfc562dac37ed5c3bb4643cbd1233fa336ff6 1039 1038 2010-01-14T15:38:26Z Tbu082 19 wikitext text/x-wiki Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. == Particle Physics Group Meetings/Seminars == * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] a6681c2e871728d492473acfa57c43f5f34b8c89 1040 1039 2010-01-14T16:05:29Z Tbu082 19 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars == * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 184e258864ab9ed820ff853f6f9452d5fcdd467a 1041 1040 2010-01-14T16:05:59Z Tbu082 19 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars == Click the dates for seminar details (slides, etc) * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 8b5b2184f3b1408359dfd0a16605fad4399b1b10 1042 1041 2010-01-15T10:46:10Z Tbu082 19 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars == Click the dates for seminar details (slides, etc) * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] edfb1cd9460b9f941972c2f24c9f163517c5d875 1043 1042 2010-01-15T10:46:59Z Tbu082 19 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 6cad5f9e79304ca77ce188a8c487e19b467104e7 1044 1043 2010-01-15T10:47:16Z Tbu082 19 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] b28a9d3ab0942b8ab687e6975021bb302dd30c36 0 269 995 2009-12-02T16:35:09Z Tbu082 19 Created page with ' == December 02 2009 seminar - Theory == * Mahdi - [[Media:Mahdi_021209.pdf]] * Nils-Erik - [[Media:Nils-Erik_021209.pdf‎]]' wikitext text/x-wiki == December 02 2009 seminar - Theory == * Mahdi - [[Media:Mahdi_021209.pdf]] * Nils-Erik - [[Media:Nils-Erik_021209.pdf‎]] f9ee38ae5b9a0db5ac87cb07605f8d073f19adc2 996 995 2009-12-02T16:35:50Z Tbu082 19 wikitext text/x-wiki * Mahdi - [[Media:Mahdi_021209.pdf]] * Nils-Erik - [[Media:Nils-Erik_021209.pdf‎]] [[ParticlePhysicsGroupMeetings|Back to meetings page]] 20bed6e1f5228cfb867590bf501786e8c0802522 998 996 2009-12-02T16:36:39Z Tbu082 19 wikitext text/x-wiki * Mahdi Purmohammadi - Natural Multi-Higgs Model with Dark Matter [[Media:Mahdi_021209.pdf]] * Nils-Erik - [[Media:Nils-Erik_021209.pdf‎]] [[ParticlePhysicsGroupMeetings|Back to meetings page]] [http://www.example.com link title] 0aab08c647cbb8a2bea5b8fbb95028766142c913 999 998 2009-12-02T16:37:00Z Tbu082 19 wikitext text/x-wiki * Mahdi Purmohammadi - Natural Multi-Higgs Model with Dark Matter [[Media:Mahdi_021209.pdf]] * Nils-Erik Bohmark - Supersymmetric theory [[Media:Nils-Erik_021209.pdf‎]] [[ParticlePhysicsGroupMeetings|Back to meetings page]] [http://www.example.com link title] 97f3372cea69e47a018089fa43f761c53e311dfb 0 270 1001 2009-12-08T16:21:23Z Ato061 22 Created page with 'Wednesday November 25, IFT Room 316, 14:00 '''* Arshak Tonoyan - Top quark charge measurement using semileptonic B-decay''' Evo details: Title: Bergen Particle Phy...' wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 '''* Arshak Tonoyan - Top quark charge measurement using semileptonic B-decay''' Evo details: Title: Bergen Particle Physics seminar Community: ATLAS Password: IFT Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=MIM9Ms2M28DDDl9v9nDa9I (Available from 13:30) df1e67182e1cf1350032d66930cee7a91874d544 1002 1001 2009-12-08T16:32:36Z Tbu082 19 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * '''Arshak Tonoyan - Top quark charge measurement using semileptonic B-decay''' Evo details: Title: Bergen Particle Physics seminar Community: ATLAS Password: IFT Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=MIM9Ms2M28DDDl9v9nDa9I (Available from 13:30) fab148dc1ebef7a3e7ea83b33b8a79d8ad577e60 1006 1002 2009-12-09T12:21:52Z Ato061 22 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * '''Arshak Tonoyan - Top quark charge measurement using semileptonic B-decay''' Evo details: Title: Bergen Particle Physics seminar Community: ATLAS Password: IFT Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=MIM9Ms2M28DDDl9v9nDa9I (Available from 13:30) * [Arshak Tonoyan - Top quark charge measurement using semileptonic B-decay] f17fa1414ec1e3a434b3d88ed6749dd229854f64 1008 1006 2009-12-09T12:23:42Z Ato061 22 wikitext text/x-wiki Wednesday November 25, IFT Room 316, 14:00 * [https://wikihost.uib.no/ift/images/9/9f/Top_charge_Tonoyan_IFTSeminar_09Dec2009.pdf Arshak Tonoyan - Top quark charge measurement using semileptonic B-decay] Evo details: Title: Bergen Particle Physics seminar Community: ATLAS Password: IFT Meeting URL: http://evo.caltech.edu/evoGate/koala.jnlp?meeting=MIM9Ms2M28DDDl9v9nDa9I (Available from 13:30) 3c2c413175526195431dbcf386557bd2471cffe3 0 137 1003 801 2009-12-08T18:30:42Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]]=== === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] f1fb589d85a4b3773512b8e3bb7b4b405d2d3349 1004 1003 2009-12-08T18:33:17Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] === [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]]=== Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 3fcccb36b86e798b524849801face6a8b549cd38 1009 1004 2009-12-09T16:36:53Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] === [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]]=== Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 7aaefcf87644ed631e3d05e5592e4a443ffaba28 1045 1009 2010-01-15T10:50:26Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[StGenisAppt|St Genis Appartment]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] === [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]]=== Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] c314c405c6a1b33524427f13787701b631080bef 1047 1045 2010-01-15T13:51:36Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] === [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]]=== Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 6081efe8ea138854025f82490bd78d7a5904d1f5 1048 1047 2010-01-15T13:56:53Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasNordugrid|Nordugrid]] * [[AtlasDPDTutorial| DPD tutorial]] === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 9d7f3d798634e88770793b88a695cda98e42da8a 1050 1048 2010-01-15T14:00:53Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|ATLAS Outreach]] === === ATLAS Software === * [[ATLASSimulationCSCWalkThrough|Simulation using CSC scripts walkthrough]] * [[AtlasDataFormats| ATLAS data formats]] * [[AtlasKlientdriftWalkthrough|Setting up athena on managed computers]] * [[AtlasDPDTutorial| DPD tutorial]] === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 9e510b73411e41de3187eea182f4e4a58f54e1ec 1051 1050 2010-01-15T14:46:50Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[ATLASOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 6f2606bde1f1c544d94302cf9b39cec84791044a 1054 1051 2010-01-15T14:48:44Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[AtlasAnalysis|ATLAS Analysis]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 56c06955ce8440a1be8226c6456f599f6ac0b7d1 1056 1054 2010-01-15T14:57:43Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[AtlasShifts|ATLAS shifts]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 87fcd46d2674a3c32d10691ad783f5696ae93f33 0 271 1005 2009-12-08T18:38:14Z Nfyal 26 Created page with 'Here is the link to the Spaatind 2010 conference [http://indico.cern.ch/conferenceDisplay.py?confId=69125] ATLAS members and students only: Here is where you need to submit yo...' wikitext text/x-wiki Here is the link to the Spaatind 2010 conference [http://indico.cern.ch/conferenceDisplay.py?confId=69125] ATLAS members and students only: Here is where you need to submit your ATLAS plots for approval before 22 of December. [https://atlas-bergen.web.cern.ch/atlas-bergen/spaatind/pmwiki.php?n=Main.HomePage] b3013dc1d595df8b8a25b307969b46e19b01e20b 6 272 1007 2009-12-09T12:22:41Z Ato061 22 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 274 1028 2009-12-12T12:14:47Z Tbu082 19 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 3 1029 858 2009-12-14T15:47:22Z St09909 38 /* Related documents for BusyBox */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== ;Revision 31 ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] <!-- ;Revision 35 ;:* Compiled with stricter constraints and higher effort settings (100 degrees celsius, 45 MHz, 1.14 V) ;:* Added "number of channels" status register. ;:* Added Stress test mode for testing only. (Disabled by default.) ;:;Download ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga2.bit busybox_fpga2.bit] --> ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] [[Category:Alice]] [[Category:Trigger]] 437a29983c763eaef58be97e5dfcebcf647d39ec 1030 1029 2009-12-18T09:46:40Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. <!-- ;Revision 35 ;:* Compiled with stricter constraints and higher effort settings (100 degrees celsius, 45 MHz, 1.14 V) ;:* Added "number of channels" status register. ;:* Added Stress test mode for testing only. (Disabled by default.) ;:;Download ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga2.bit busybox_fpga2.bit] --> =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added and an updated register table exists on the wiki : [[Busy_Box_and_related/BusyBox_Registers]] In short: 1)Number of implemented channels. This number is actually the same as the generic g_num_channels. 2)Current Trigger Event Info 3)Current Trigger Event Error 4)Newest Trigger Event Info 5)Newest Trigger Event Error ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] [[Category:Alice]] [[Category:Trigger]] 2227eb0eb52063e77b4465bd7eb72c7c6eddc5b9 1031 1030 2009-12-18T10:42:36Z St09909 38 /* Revision 41 */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. <!-- ;Revision 35 ;:* Compiled with stricter constraints and higher effort settings (100 degrees celsius, 45 MHz, 1.14 V) ;:* Added "number of channels" status register. ;:* Added Stress test mode for testing only. (Disabled by default.) ;:;Download ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://folk.uib.no/st09909/revision35/busybox_fpga2.bit busybox_fpga2.bit] --> =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added and an updated register table exists on the wiki : [[Busy_Box_and_related/BusyBox_Registers|BusyBox Registers]] In short: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] [[Category:Alice]] [[Category:Trigger]] 82dccc690224c2ba3d8d5c02e11aa172cae40054 1032 1031 2009-12-18T10:47:03Z St09909 38 /* Compiled BusyBox Firmware Versions */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added and an updated register table exists on the wiki : [[Busy_Box_and_related/BusyBox_Registers|BusyBox Registers]] In short: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] [[Category:Alice]] [[Category:Trigger]] 97621caee97e6159a548a3fe53885a009db1959a 1033 1032 2009-12-18T14:13:40Z St09909 38 /* Related documents for BusyBox */ wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added and an updated register table exists on the wiki : [[Busy_Box_and_related/BusyBox_Registers|BusyBox Registers]] In short: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 1fc2d0bc986ceb2694cbc22119ca35af4d19be62 0 21 1035 910 2010-01-06T09:11:45Z Dfe002 7 /* Meetings and conferences */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * Our weekly labmeeting is Tuesdays 11:15 in room 332. * 14.01.09: MedViz annual conference - project presentations (http://www.medviz.uib.no/) * 02.01. - 08.01.10: Spåtind meeting on particle physics (http://indico.cern.ch/event/spaatind-2010) * 15.02. - 20.02.10: Vienna conference on Instrumentation - Deadline 16.11.09. (http://vci.hephy.at/2010/) * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany === For internal use === [[material]] that can be used in official presentations. c61c223ce2938d0951ab1850e826e3d052d5ebbf 0 225 1052 767 2010-01-15T14:47:59Z Pro027 29 moved [[ATLASOutreach]] to [[HEPOutreach]] wikitext text/x-wiki == ATLAS outreach == === Talks === === Images === === Links === 8a7822700f05cb630d09da1d418f491af49044b0 1055 1052 2010-01-15T14:49:02Z Pro027 29 wikitext text/x-wiki == HEP outreach == === Talks === === Images === === Links === 7f1093cfc56767d49fdc2a5e84442485879d1ecd 0 137 1057 1056 2010-01-15T15:05:51Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [http://atlas.web.cern.ch/Atlas/GROUPS/GENERAL/SCINOTES/pub_templates.html ATLAS ROOT and paper templates] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] d081b2561a15186e4e0dff2a16bf7766b36b3f8a 1058 1057 2010-01-15T15:10:11Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASEarlyData|ATLAS Early Data]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 5a55c86c76a446a654fc668666e024478ac51283 1059 1058 2010-01-15T15:12:38Z Pro027 29 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[AtlasSafety|Safety training for ATLAS work]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] d4b37132ee754eb2f8e5150e87b0745230a198d3 1060 1059 2010-01-15T16:20:10Z Ato061 22 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] A calendar for ATLAS is available [[http://www.google.com/calendar/embed?src=vu2co93q6o23ru0mok01ujqavk%40group.calendar.google.com&ctz=Europe/Stockholm|at google calendar]] If you have a gmail account you can be granted edit access to this calendar... To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 2f606b4b65b093f77d7d2aa6737e28c87c566127 1061 1060 2010-01-27T10:39:07Z Tbu082 19 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 97446d8e531ef3f754d4c61680568ff06a839a15 0 33 1062 350 2010-02-01T11:54:48Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /prog/altera/vhdl/apex20ke [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[Category:Mikroelektronikk]] d10447875b77830b9ad1572127f214431d2a1b51 1063 1062 2010-02-01T11:55:19Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /prog/altera/vhdl/apex20ke [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[Category:Mikroelektronikk]] 9f3e71d9041eb70f781a30a9d4e934c42c5558f4 1065 1063 2010-02-01T12:41:31Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: * vmap apex20ke /prog/altera/vhdl/apex20ke [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[Category:Mikroelektronikk]] 6f5917343c5b2cc2dfbaf3f5b637d03e2fe6ea0a 1097 1065 2010-02-15T11:02:51Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap apex20ke /prog/altera/vhdl/apex20ke vmap lpm /prog/altera/vhdl/lpm vmap altera_mf /prog/altera/vhdl/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[Category:Mikroelektronikk]] bf64728ab8414bdc879bb25977aa9738c74f327b 1100 1097 2010-02-15T12:42:47Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[Category:Mikroelektronikk]] 024f97dc2c7c27ffcf31dd8a1d13b9979d0a4368 1102 1100 2010-02-16T08:28:37Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[http://www.edn.com/contents/images/46098.pdf 10 tips for generating reusable VHDL]] [[Category:Mikroelektronikk]] 57050db84442472b2e05c797e52847be8e9ade40 1103 1102 2010-02-17T09:13:15Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[http://www.edn.com/contents/images/46098.pdf 10 tips for generating reusable VHDL]] [[http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems]] [[Category:Mikroelektronikk]] e0a7eb5ad394e7d88c32201adab624e5784a57d4 1104 1103 2010-02-17T09:15:50Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[http://www.edn.com/contents/images/46098.pdf 10 tips for generating reusable VHDL]] [[Category:Mikroelektronikk]] 57050db84442472b2e05c797e52847be8e9ade40 0 36 1064 394 2010-02-01T11:59:36Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen). Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/altera8.0 </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/simulation/modelsim/prosjektnavn.vho' (i vårt tilfelle 'alu/add_sub_alu_temp_1/simulation/modelsim/add_sub_alu.vho'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). ''NB. Simulatoren feilar hvis vi har beheld entity deklarasjonen i begge filane som skal inkluderast i testbenken. Dette kan vi løyse enten ved å ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, eller ved å fjerne enitity deklarasjonen i den opprinnelige koden.'' ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 91877a63f4dff44cdc15201051e2b990908a193a 1094 1064 2010-02-14T16:22:54Z Ave082 33 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Sett opp lisensen i Quartus ved å starte Quartus, og velg menyen Precision er eit program som bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/altera8.0 </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). ''NB. Simulatoren feilar hvis vi har beheld entity deklarasjonen i begge filane som skal inkluderast i testbenken. Dette kan vi løyse enten ved å ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, eller ved å fjerne enitity deklarasjonen i den opprinnelige koden.'' ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 672d8e42ff6cc71f474b3b23fd47d7407e24586d 1096 1094 2010-02-15T09:52:04Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens(i vårt tilfelle valgte vi Altera APEX 20KE med frekvens 200MHz). For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/altera9.1/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). ''NB. Simulatoren feilar hvis vi har beheld entity deklarasjonen i begge filane som skal inkluderast i testbenken. Dette kan vi løyse enten ved å ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, eller ved å fjerne enitity deklarasjonen i den opprinnelige koden.'' ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] d3352d1d8cd54c1340ab45d0d0c1ddd6279f871a 1098 1096 2010-02-15T12:06:54Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone III med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/altera9.1/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Legg til mapping av alterabiblioteket vmap apex20ke /prog/altera/vhdl/apex20ke Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). ''NB. Simulatoren feilar hvis vi har beheld entity deklarasjonen i begge filane som skal inkluderast i testbenken. Dette kan vi løyse enten ved å ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, eller ved å fjerne enitity deklarasjonen i den opprinnelige koden.'' ==Simulering med timing== <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 15fc3ad7004a5eb31520872f6438f36b3c1d1253 1099 1098 2010-02-15T12:41:01Z Nfyku 4 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone III med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/altera9.1/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii </pre> Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). ''NB. Simulatoren feilar hvis vi har beheld entity deklarasjonen i begge filane som skal inkluderast i testbenken. Dette kan vi løyse enten ved å ha ulike entitynavn på den synthesiserte og opprinnlige komponenten, eller ved å fjerne enitity deklarasjonen i den opprinnelige koden.'' ==Simulering med timing== Eksemple på start av simulering med timing: <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] f13f3be1cc8ff459070f260ae536177d858ac6a1 1101 1099 2010-02-15T22:48:16Z Ave082 33 wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone III med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/altera9.1/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii </pre> Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk = '1' AND clk'LAST_VALUE = '0') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk = '1' AND clk'LAST_VALUE = '0') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= null; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '0', '1' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] d0dfde8fdb2486620a22199d176fae0698306ddf 0 25 1066 653 2010-02-01T13:21:13Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Øvingsoppgaver i PHYS321 [[Category:Mikroelektronikk]] 73939543f171eeaae4533c8a98e8b2ee44ca8514 1107 1066 2010-02-17T09:18:32Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 [[Category:Mikroelektronikk]] 461e8157ec086ce71614bf871abb41ed91457f4d 0 3 1067 1033 2010-02-04T09:58:29Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 47===== ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] a525533763a6170a51f6edf28b48a656ef1d8230 1072 1067 2010-02-04T15:24:37Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] d90d94050c8caae7879e6c67619273f2456d1b5c 0 242 1068 967 2010-02-04T10:11:44Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Contol Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 47 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 298de2eeb4cfea5b9309aa0a7007e32bcdd7e37b 1069 1068 2010-02-04T10:45:10Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 48 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 1ccc486bf54a9201398fc95f88ad836feca66090 1070 1069 2010-02-04T10:47:22Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 11:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 48 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 30bf07d1fca1d7b031fbafb182df7b42c3d959bb 1071 1070 2010-02-04T13:55:33Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 48 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 93eb51493cf31c89c3a0469dd9471b0d37c823a3 0 31 1073 94 2010-02-07T13:37:10Z Ave082 33 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC station er startet fra "IC studio", http://doc.uib.no/wiki/ICStudio. ==Create cell== Etter at skjemaet er laget går du ut igjen i prosjekt vinduet, velger prosjektet ditt og høyreklikker i den blå Cell-view ruten og velger create new view. Sett "View Type" til Layout og trykk finish. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 72810bce9593baca2ab028f105a61c38fbd11ddf 1083 1073 2010-02-08T11:07:05Z Ave082 33 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC studio er startet, se [https://wikihost.uib.no/ift/index.php/IC_studio IC studio]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 894720d1738637c3a200b12e680d935f05aa35ce 1084 1083 2010-02-08T11:08:03Z Ave082 33 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: <br/> * DRC (Design rule check) <br/> * LVS (Layout versus schematic test) <br/> * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 <pre>file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html</pre> Vi antar nå at IC studio er startet, se [https://wikihost.uib.no/ift/index.php/IC_studio IC studio]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 509d8ada3d3173fb333e3015c144fb9b4994a693 1085 1084 2010-02-08T11:08:44Z Ave082 33 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: * DRC (Design rule check) * LVS (Layout versus schematic test) * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 <pre>file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html</pre> Vi antar nå at IC studio er startet, se [https://wikihost.uib.no/ift/index.php/IC_studio IC studio]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. e22dcf84798d28035fc1e36010983ff82d41e67d 1086 1085 2010-02-08T11:09:36Z Ave082 33 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: * DRC (Design rule check) * LVS (Layout versus schematic test) * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC studio er startet, se [https://wikihost.uib.no/ift/index.php/IC_studio IC studio]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de *design rules* som gjelder for prosessen. DRC sjekker *ikke* om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg *ICrules* --> *Check*. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg *Options...* og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg *OK* begge steder for å kjøre DRC. Bruk så knappene *First* og *Next* for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under *Options...* trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg *File* --> *Logic* --> *Close*. Fra paletten: Velg *ICtrace(M)* <br/> Klikk på *SETUP* (den blå knappen). [[Image:lvs_setup_button.png]] Klikk på *LVS* og fyll ut dialogboksen tilsvarende figuren under. [[Image:lvs_2.png]] Trykk på knappen *Setup LVS...* <br/> Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da vi klikket på den blå setup-knappen. [[Image:lvs_setup_2.png]] Klikk *OK* begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg *Logic* --> *Open*, og angi stien til viewpointet (samme som *Source Name* i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg *ICextract (M)* <br/> Lukk eventuelle åpne *logic*. <br/> Klikk *Lumped* og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk *Lib/Temp/Inc* og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg *Annotations --> Merge all* <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 31e4fbc668e88e78de47687e5fe5603a8782728a 0 105 1074 920 2010-02-08T09:32:10Z Ave082 33 wikitext text/x-wiki [http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow] [http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial] [http://pages.cs.wisc.edu/~david/courses/cs755/cs755/ VLSI System Design course with tutorials] [http://www.swarthmore.edu/NatSci/tali/E77/Mentor_Tutorials/tutorials.htm Mentor Graphic Tutorials] [http://www.ele.uri.edu/Research/cherry/mentor_tutorial/index.html Mentor Graphics IC Layout & Verification Tutorial] [http://vlsi.ee.hacettepe.edu.tr/tutorials/tutorial_yildirim/tutorial.htm ASIC Design Flow Tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_1.pdf Design arcithect tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_2.pdf IC studio tutorial] [http://people.ee.duke.edu/~jmorizio/ece261/LABMANUALS/ Mentor tutorials relativt oppdaterte] [[Category:Mikroelektronikk]] 7df8519ed80d25f04e108cd76a8750f813e077b2 0 28 1075 939 2010-02-08T09:49:37Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. Om du ønsker å bruke Mentor programmene fra en Windows pc så se denne forklaringen [[Mentor i windows]] ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". 062d723039b8c4cf70efa4931cb8652e4140553b 1080 1075 2010-02-08T10:18:48Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. Om du ønsker å bruke Mentor programmene fra en Windows pc så se denne forklaringen [[Mentor i Windows]] ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. ==Bruk av IC station== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og Schematic under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. Her finner du en kort innføring i tegning av utlegg med "IC station", [[ICStation]] = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". fef7fd690f191c388bc557dc9cbc315c3d84e71d 1082 1080 2010-02-08T10:21:59Z Ave082 33 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. Om du ønsker å bruke Mentor programmene fra en Windows pc så se denne forklaringen [[Mentor i Windows]] ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". 242ed190f4be94d0ad14910c0b3455f9e5486ac5 0 276 1076 2010-02-08T10:12:46Z Ave082 33 Created page with 'Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] Lagre Putty på skrivebordet eller lignend...' wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] Lagre Putty på skrivebordet eller lignende og start det. På "Host Name" skal det stå portal1.ift.uib.no På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn <pre> +bs -wm -emulate3buttons -fp tcp/localhost:7100 </pre> etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hviss programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. 1a83b49266ffa6ab3323282f4c081c2a64276f40 1077 1076 2010-02-08T10:13:16Z Ave082 33 wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] Lagre Putty på skrivebordet eller lignende og start det. På "Host Name" skal det stå portal1.ift.uib.no På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn <pre> +bs -wm -emulate3buttons -fp tcp/localhost:7100 </pre> etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hviss programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. 24b82ace16dd75c61efd8708decff6ec0caa6420 1078 1077 2010-02-08T10:14:30Z Ave082 33 wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] Lagre Putty på skrivebordet eller lignende og start det. På "Host Name" skal det stå portal1.ift.uib.no På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn <pre> +bs -wm -emulate3buttons -fp tcp/localhost:7100 </pre> etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hviss programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. 8060ae1a6cd392933a487a850c7f09da8341c29d 1079 1078 2010-02-08T10:15:54Z Ave082 33 wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] Lagre Putty på skrivebordet eller lignende og start det. På "Host Name" skal det stå portal1.ift.uib.no På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn <pre> +bs -wm -emulate3buttons -fp tcp/localhost:7100 </pre> etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hvis programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. 7683cb4b3852900a483917667df968d50e165f6d 0 34 1087 201 2010-02-08T20:24:04Z Ave082 33 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa== Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando i et terminalvindu og start deretter et nytt skall. <pre> ssh -X mikroserver1 /prog/design_kits/micro.init.csh eller /prog/design_kits/micro.init.bash </pre> Senere skriver man følgende i et teminalvindu: <pre> ssh -X mikroserver1 mentor questa </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs eller den innebygde teksteditoren i Questa. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Signals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Variables for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] d5f7ab844b789fe113b36b6b2badcfc91cb55c8c 1088 1087 2010-02-09T07:47:11Z Ave082 33 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa== Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando i et terminalvindu og start deretter et nytt skall. <pre> ssh -X mikroserver1 /prog/design_kits/micro.init.csh eller /prog/design_kits/micro.init.bash </pre> Senere skriver man følgende i et teminalvindu: <pre> ssh -X mikroserver1 mentor questa </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs eller den innebygde teksteditoren i Questa. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Wave Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Objects for å kikke på innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] 21772ec932ac4c266710cfd10b3a808d0d83e484 1089 1088 2010-02-10T11:14:39Z Ave082 33 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa== Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando i et terminalvindu og start deretter et nytt skall. <pre> ssh -X mikroserver1 /prog/design_kits/micro.init.csh eller /prog/design_kits/micro.init.bash </pre> Senere skriver man følgende i et teminalvindu: <pre> ssh -X mikroserver1 mentor questa </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs eller den innebygde teksteditoren i Questa. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Før man kan kompilere koden må man sette mappen man ønsker at biblioteket av de kompilerte kodene skal ligge. Dette kan gjøres med: <pre> vlib work </pre> Mappen work blir da bibliotekmappen. Kommandoen (aliaset) ''mentor'' sørger for velge riktige stier og miljøvariable. Når dette er gjort kompileres koden ved <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil disse listes opp. Feilmeldingen har en henvisning til linjenummer, som kan brukes til å lokalisere feilen i teksteditoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Source * View > Wave Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] ed76b6ac82aef2503c56eb93d3a997518211254f 1095 1089 2010-02-14T19:18:44Z Ave082 33 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa== Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando i et terminalvindu og start deretter et nytt skall. <pre> ssh -X mikroserver1 /prog/design_kits/micro.init.csh eller /prog/design_kits/micro.init.bash </pre> Senere skriver man følgende i et teminalvindu: <pre> ssh -X mikroserver2 mentor questa </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] 762ee28b226b9f97921e6fdf1da24ad80950fb91 0 35 1090 68 2010-02-10T11:16:00Z Ave082 33 wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscilliasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. fdb6beb7587e8e70cefb483fc238914f702842dc 1091 1090 2010-02-10T11:16:49Z Ave082 33 wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscilliasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. 09df084b7fdc0ee4f8747852c0b3c4953f52a570 1092 1091 2010-02-10T11:55:41Z Ave082 33 wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscilliasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. fb07e73ed90f53aa91aff3f24d63550571bc0796 1093 1092 2010-02-10T12:05:03Z Ave082 33 wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscilliasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen. ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. cceccc546b87fbba41afc757168d40676ba32ca3 0 169 1105 468 2010-02-17T09:17:54Z Nfyku 4 moved [[PHYS321]] to [[Øvingsoppgaver PHYS321]] wikitext text/x-wiki == Øvingsoppgaver PHYS321 == === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC_studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. [[Category:Mikroelektronikk]] de4199254dc8d8b165f9e829fc8bd537bcb66eac 0 278 1106 2010-02-17T09:17:54Z Nfyku 4 moved [[PHYS321]] to [[Øvingsoppgaver PHYS321]] wikitext text/x-wiki #REDIRECT [[Øvingsoppgaver PHYS321]] c796f4400ddfaf3e23df76087ae265a1591eab75 0 278 1108 1106 2010-02-17T09:35:18Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Nettressurser === [[http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems]] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] d29dc377ceadb27a1fd4e95ce3505fb186a8426b 0 169 1109 1105 2010-02-17T09:36:51Z Nfyku 4 wikitext text/x-wiki === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC_studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. === VHDL === Utfyllende tekst kommer [[Category:Mikroelektronikk]] 262f843d865a30cfe0feb9cdb71d06f4a8117bf4 0 276 1110 1079 2010-02-17T09:38:06Z Nfyku 4 Protected "[[Mentor i windows]]" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite)) wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] Lagre Putty på skrivebordet eller lignende og start det. På "Host Name" skal det stå portal1.ift.uib.no På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn <pre> +bs -wm -emulate3buttons -fp tcp/localhost:7100 </pre> etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hvis programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. 7683cb4b3852900a483917667df968d50e165f6d 1132 1110 2010-02-18T12:05:42Z Nfyku 4 Unprotected "[[Mentor i windows]]" wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] Lagre Putty på skrivebordet eller lignende og start det. På "Host Name" skal det stå portal1.ift.uib.no På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn <pre> +bs -wm -emulate3buttons -fp tcp/localhost:7100 </pre> etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hvis programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. 7683cb4b3852900a483917667df968d50e165f6d 1133 1132 2010-02-18T12:09:57Z Nfyku 4 wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] ==Koble til mikroserver2 med tunnel gjennom portal1== # Lagre Putty på skrivebordet eller lignende og start det. # På "Host Name" skal det stå portal1.ift.uib.no # På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" # Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". # Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. # Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. # Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. ==Starte grafisk grensensnitt== Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn +bs -wm -emulate3buttons -fp tcp/localhost:7100 etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hvis programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. [[Category:Mikroelektronikk]] 32c88e6759c28605d7c0a6d87ddc29ef72909ca7 1134 1133 2010-02-18T12:10:57Z Nfyku 4 moved [[Mentor i windows]] to [[Xming]] wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] ==Koble til mikroserver2 med tunnel gjennom portal1== # Lagre Putty på skrivebordet eller lignende og start det. # På "Host Name" skal det stå portal1.ift.uib.no # På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" # Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". # Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. # Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. # Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. ==Starte grafisk grensensnitt== Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn +bs -wm -emulate3buttons -fp tcp/localhost:7100 etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hvis programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. [[Category:Mikroelektronikk]] 32c88e6759c28605d7c0a6d87ddc29ef72909ca7 1137 1134 2010-02-18T12:12:53Z Nfyku 4 wikitext text/x-wiki Programmer som trengs: [http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe Putty] [http://sourceforge.net/projects/xming/ Xming] ==Koble til server med tunnel gjennom portal-maskin== # Lagre Putty på skrivebordet eller lignende og start det. # På "Host Name" skal det stå portal1.ift.uib.no # På venstre side så trykker du på "Keyboard" og haker av for "Control-H" under "The Backspace Key" # Lengre nede i menyen på venstre side så utvider du SSH og trykker på Auth, merk av for "Allow agent forwarding". # Trykk deretter på X11 på menyen til venstre og hak av for "Enable X11 forwarding" og skriver localhost:0 i "X display location ruten. # Trykk så på Tunnels i menyen til venstre og skriv 7100 i "Source port" og mikroserver2:7100 i "Destination". Trykk så på Add. # Velg så Session i menyen til venstre igjen og skriv inn ett navn til koblingen din i "Saved Session" fex uib og trykk på save. ==Starte grafisk grensensnitt== Installer så Xming, trykk neste på de fleste menyene men på nest siste elns så haker du av for å legge en snarvei til xming på skrivebordet. Når det er ferdig installert så høyreklikker du på snarveien på skrivebordet og skriver inn +bs -wm -emulate3buttons -fp tcp/localhost:7100 etter det som står i "Mål" ruten. Når du så skal starte så er det bare å åpne putty, trykke load på koblingen du lagret og trykk open. Tast inn brukernavn og passord, samme som på mikroserver2. Når du er logget inn skriver du <pre>ssh -X mikroserver2</pre> og skriver passord på nytt. Så starter du Xming programmet fra snarveien, hvis programmet allerede kjører så må du lukke det ved å høyreklikke på ikonet i systemtray og velg exit først. Dernest kan du starte programmet du vil. [[Category:Mikroelektronikk]] 52901c365fe8ef885edb2ea230eac64c9cf6be3c 0 25 1111 1107 2010-02-17T10:03:03Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare [[Category:Mikroelektronikk]] 091d37ed8d11ce006fe1c5860b39132a9c0bcb58 0 279 1112 2010-02-17T10:03:55Z Nfyku 4 Created page with '[[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[Category:Mikroelektronikk]]' wikitext text/x-wiki [[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[Category:Mikroelektronikk]] 2659e20baa9fedcc5a072a57b3416109e4781ef3 1120 1112 2010-02-17T10:28:39Z Nfyku 4 wikitext text/x-wiki [[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[SSH Innlogging]] Hvordan logge inn med ssh fra Windows-PC [[Category:Mikroelektronikk]] c1db41197c3cb01b5ca5ae6ebcf0a629da47fd32 1121 1120 2010-02-17T10:29:15Z Nfyku 4 wikitext text/x-wiki [[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[SSH innlogging]] Hvordan logge inn med ssh fra Windows-PC [[Category:Mikroelektronikk]] 8912828ec1976565d357343dec78c6d3123f8bf1 1136 1121 2010-02-18T12:12:14Z Nfyku 4 wikitext text/x-wiki [[SSH innlogging]] Hvordan logge inn med ssh fra remote Windows-PC [[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[Xming]] Hvordan bruke Xming for å logge inn fra remote Windows-PC [[Category:Mikroelektronikk]] 347a761fc13567fac4b5ae6f99ee79f98bd97c8b 1139 1136 2010-02-19T11:46:14Z Nfyku 4 wikitext text/x-wiki [[SSH innlogging]] Hvordan logge inn med ssh fra remote Windows-PC [[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[Xming]] Hvordan bruke Xming for å logge inn fra remote Windows-PC [[http://www.msc.rl.ac.uk/europractice/software/mentor.html Europractice Mentor Graphics Software Overview]] [[http://www.msc.rl.ac.uk/europractice/software/cadence.html Europractice Cadence Software Overview]] [[Category:Mikroelektronikk]] 753f249ae247f6cab5a60a10be63d122f2813130 0 280 1113 2010-02-17T10:11:06Z Nfyku 4 Created page with '==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan ...' wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om SSH innloging). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024×768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280×1024 kan du prøve med en VNC desktop på 1262×947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: * vncserver -geometry 1006×701 * vncserver -geometry 1262×947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot din VNC server når du ikke er på universitetet, les VNC-SSH innlogging ===Logout fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt desktop nummeret Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. [[Category:Mikroelektronikk]] 0702d1be2bc282903c6b88de982bec83c2fb8954 1114 1113 2010-02-17T10:12:54Z Nfyku 4 wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om [[SSH innloging]]). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024×768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280×1024 kan du prøve med en VNC desktop på 1262×947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: * vncserver -geometry 1006×701 * vncserver -geometry 1262×947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot din VNC server når du ikke er på universitetet, les VNC-SSH innlogging ===Logout fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt desktop nummeret Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. [[Category:Mikroelektronikk]] ef95e47c92567e21db3ed345d34a73a391b53605 1124 1114 2010-02-17T10:31:44Z Nfyku 4 wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om [[SSH innlogging]]). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024×768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280×1024 kan du prøve med en VNC desktop på 1262×947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: * vncserver -geometry 1006×701 * vncserver -geometry 1262×947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot din VNC server når du ikke er på universitetet, les VNC-SSH innlogging ===Logout fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt desktop nummeret Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. [[Category:Mikroelektronikk]] f63b726b539080174163e7f9021c8bd437e67f3a 1125 1124 2010-02-17T10:38:33Z Nfyku 4 wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om [[SSH innlogging]]). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024×768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280×1024 kan du prøve med en VNC desktop på 1262×947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: * vncserver -geometry 1006×701 * vncserver -geometry 1262×947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot VNC serveren når du ikke er på universitetet, les [[SSH tunnel]] ===Logout fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt desktop nummeret Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. [[Category:Mikroelektronikk]] 681cd84434e6bf418bc4a9939dd69c52a87974fe 1142 1125 2010-02-22T18:53:48Z Ave082 33 wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om [[SSH innlogging]]). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024x768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280x1024 kan du prøve med en VNC desktop på 1262x947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: * vncserver -geometry 1006x701 * vncserver -geometry 1262x947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot VNC serveren når du ikke er på universitetet, les [[SSH tunnel]] ===Logout fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt desktop nummeret Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. [[Category:Mikroelektronikk]] 1f296d926add648e653ee33311a82c9fe129b4af 1143 1142 2010-02-22T21:33:26Z Ave082 33 wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om [[SSH innlogging]]). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024x768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280x1024 kan du prøve med en VNC desktop på 1262x947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: * vncserver -geometry 1006x701 * vncserver -geometry 1262x947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot VNC serveren når du ikke er på universitetet, les [[SSH tunnel]] ===Logout fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt desktop nummeret Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. ====Skifte window manager==== Kontoen er default satt opp til å bruke en enkel resursbesparende window manager, dvs programmet som viser alle vinduene dine. Dette kan være greit om du sitter på en internett linje med lav kapasitet, men den kan bli litt vanskelig å jobbe med. Om du vil ha en fullverdig window manager så må du redigere filen xstartup nano ~/.vnc/xstartup Fjern # tegnet foran linje 4 og 5 Trykk Ctrl-x deretter j og deretter enter og så må du starte vnc serveren på nytt. [[Category:Mikroelektronikk]] 4521b548a54c3643949643ecb3c47b99e5972d4d 1144 1143 2010-02-22T21:34:44Z Ave082 33 wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om [[SSH innlogging]]). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024x768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280x1024 kan du prøve med en VNC desktop på 1262x947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: * vncserver -geometry 1006x701 * vncserver -geometry 1262x947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot VNC serveren når du ikke er på universitetet, les [[SSH tunnel]] ===Logout fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt desktop nummeret Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. ===Skifte window manager=== Kontoen er default satt opp til å bruke en enkel resursbesparende window manager, dvs programmet som viser alle vinduene dine. Dette kan være greit om du sitter på en internett linje med lav kapasitet, men den kan bli litt vanskelig å jobbe med. Om du vil ha en fullverdig window manager så må du redigere filen xstartup nano ~/.vnc/xstartup Fjern # tegnet foran linje 4 og 5. Trykk Ctrl-x deretter j og deretter enter og så må du starte vnc serveren på nytt. [[Category:Mikroelektronikk]] 11021f371b63da0e7ff97b666fbaa014f068a54d 1145 1144 2010-02-23T08:22:04Z Nfyku 4 wikitext text/x-wiki ==VNC-innlogging mot server== Du kan koble til og fra din egen VNC server så ofte du vil. Desktopen blir bevart nøyaktig slik du forlot den.Du bør ha forståelse for hvordan du kan liste ut og rydde opp i egne prosesser. Det som er største forskjellen i forhold til enkel VNC innlogging er at du først må starte opp en VNC server på den maskinen du velger å bruke. ===SSH til server=== Start et SSH vindu og SSH til mikroserver2.ift.uib.no, eller til en annen server (les om [[SSH innlogging]]). ===Start egen VNC server=== Start din egen VNC server, dette blir en virtuell desktop (nesten en virtuel GNU/Linux-arbeidsstasjon) som du kan koble til og fra uten at programmene i den virtuelle desktoppen avsluttes ! Du bestemmer selv dimensjonen på VNC desktopen, for de som kjører en windows oppløsning på 1024x768 vil en VNC desktop på 1006×701 passe bra, det gir plass til windows start linja, samt windows ramme og knapper på VNC vinduet. Kjører du med 1280x1024 kan du prøve med en VNC desktop på 1262x947. Får du scroll-bar’s på VNC vinduet, har du valgt for stor VNC-desktop, avslutt da VNC-serveren (se hvordan under) og prøv igjen med en mindre desktop. Start din egen vncserveren med en av følgende kommandoer, eller velg din egen desktop størrelse: vncserver -geometry 1006x701 vncserver -geometry 1262x947 Oppgi et passord, være sikkerhetsbevist og velg et godt passord men ikke så godt at du må skrive det ned. Du kan senere endre passordet med kommandoen vncpasswd Merk at du kun skal starte max en stk VNC server på max en Unix-server (du må aldri kjøre vncserver kommandoen flere ganger etter hverandre!). Om du f.eks. ønsker å endre størrelsen på desktop, skal du først stoppe den serveren du har, før du starter en ny VNC server – les nedenfor hvordan du stopper en eksisterende VNC server. Når VNC serveren starter vil den prøve display nummer 4,5,6.. osv. til den finner et som ikke er i bruk. Når det er funnet opprettes en ny VNC desktop New 'mikroserver2.ift.uib.no:6 (kjetil)' desktop is mikroserver2.ift.uib.no:6 Noter deg servernavnet (her mikroserver2.ift.uib.no) og desktop nummeret (her 6). Når VNC serveren har startet kan du logget ut fra SSH (les om det i SSH innloging). ===Login mot VNC server=== Merk at dette kun kan gjøres fra Institutt for Fysikk og Teknologis nettverk, er du på utsiden, må du kjøre VNC via en SSH-tunnel. Om du ikke allerede har installer VNC Viewer, installer og start Viewer’en som forklart under Metode 1. I Server: feltet skriver du inn adressen til din egen VNC server (i eksempelet over var det mikroserver2.ift.uib.no:6) og click OK så skal du taste inn passordet du gav når du startet VNC Serveren. Det var det, nå er du inlogget på din virtuelle desktop og kan trygt lukke windows VNC Viewer vinduet uten at du mister noe. Om du ønsker å koble deg opp mot VNC serveren når du ikke er på universitetet, les [[SSH tunnel]] ===Logge ut fra VNC server=== ====Avslutte for dagen==== Om du bare skal avslutte for dagen og har tenkt å forsette i morgen, da lukker du bare VNC Viewer vinduet ved å klikke på X oppe i høyre hjørne (raskt og brutalt). Din virtuelle desktop vil fortsatt eksistere på serveren og er klar for på-logging (tilkobling) ====Avslutte og stoppe VNC serveren==== Om du vil stoppe og starte VNC serveren på ny (f.eks. med en annen desktop størrelse) eller om du ikke skal bruke VNC serveren din på en stund, bør du stoppe serveren for å spare ressurser (som memory og cpu). Først stopper du dine programmer, koble deg opp mot din VNC server (som forklart ovenfor), avslutte alle aktive program og logge ut, velge Log Out under Desktop menyen. Lukk deretter VNC Viewer vinduet med X oppe i høyre hjørne. Så må du avslutte selve VNC serveren, SSH inn på serveren (maskinen du kjører VNC serveren på) og kjøre kommandoen vncserver -kill :ditt_desktop_nummer Om du ikke husker ditt desktop nummer kan du kjøre følgende kommando for å liste ut VNC server prosessen din (merk at det kun skal komme opp en Xvnc prosess, kommer det flere har du startet Xvnc-serveren mer enn en gang og det skal man ikke gjøre…) ps -fu $USER | grep Xvnc | grep -v grep | cut -c1-84 Dessverre så kan det henge igjen noen prosesser, og siden slike kan bruke mye minne og/eller cpu, er det viktig å sjekke at alle dine prosesser virkelig er fjernet og at du ikke har noen løpske eller glemte prosesser. Når VNC serveren din er stoppet og alle prosessene dine er fjernet, kan du starte ny VNC server, om du ønsker det. ===Skifte window manager=== Kontoen er default satt opp til å bruke en enkel ressursbesparende window manager, dvs programmet som viser alle vinduene dine. Dette kan være greit om du sitter på en internett linje med lav kapasitet, men den kan bli litt vanskelig å jobbe med. Om du vil ha en fullverdig window manager så må du redigere filen xstartup nano ~/.vnc/xstartup Fjern # tegnet foran linje 4 og 5. Trykk Ctrl-x deretter j og deretter enter og så må du starte vnc serveren på nytt. [[Category:Mikroelektronikk]] c0d87bfce57997fe5382a5f4f3829f1af3fc6661 0 281 1115 2010-02-17T10:18:33Z Nfyku 4 Created page with '==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tek...' wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk WinX eller VNC for kjøre grafiske programmer. ===Installering=== Hent og installer SSH (lagre på desktop og kjør). Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[http://bs.uib.no/]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] eb43b9c1ec65960a25c0291b937872dc4ddeb4a4 1116 1115 2010-02-17T10:18:59Z Nfyku 4 Protected "[[SSH innloging]]" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite)) wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk WinX eller VNC for kjøre grafiske programmer. ===Installering=== Hent og installer SSH (lagre på desktop og kjør). Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[http://bs.uib.no/]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] eb43b9c1ec65960a25c0291b937872dc4ddeb4a4 1117 1116 2010-02-17T10:19:33Z Nfyku 4 Unprotected "[[SSH innloging]]" wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk WinX eller VNC for kjøre grafiske programmer. ===Installering=== Hent og installer SSH (lagre på desktop og kjør). Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[http://bs.uib.no/]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] eb43b9c1ec65960a25c0291b937872dc4ddeb4a4 1118 1117 2010-02-17T10:26:11Z Nfyku 4 wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk WinX eller VNC for kjøre grafiske programmer. ===Installering=== Hent og installer [[http://it.uib.no/?link_id=1530&sublink_id=2469&content_id=3726&modus=vis_seek_resultat&prodid=105 SSH]]. Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[http://bs.uib.no/]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] 93346bd3c3e643e487a6d4d240764499dee6d073 1119 1118 2010-02-17T10:27:14Z Nfyku 4 wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk WinX eller VNC for kjøre grafiske programmer. ===Installering=== Hent og installer [[http://it.uib.no/?link_id=1530&sublink_id=2469&content_id=3726&modus=vis_seek_resultat&prodid=105 SSH]]. Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[https://bs.uib.no/?module=issues&action=new&gid=20 Brukerstøtte for IFT]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] 119a90f5ab3d12013c0b69f38388e8b6e7b43264 1122 1119 2010-02-17T10:30:52Z Nfyku 4 moved [[SSH innloging]] to [[SSH innlogging]] wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk WinX eller VNC for kjøre grafiske programmer. ===Installering=== Hent og installer [[http://it.uib.no/?link_id=1530&sublink_id=2469&content_id=3726&modus=vis_seek_resultat&prodid=105 SSH]]. Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[https://bs.uib.no/?module=issues&action=new&gid=20 Brukerstøtte for IFT]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] 119a90f5ab3d12013c0b69f38388e8b6e7b43264 1129 1122 2010-02-17T14:10:12Z Nfyku 4 wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk for eksempel WinX, [[http://www.tightvnc.com/ Tight VNC]] eller [[http://www.ii.uib.no/~bjorge/NX/ NX]] for kjøre grafiske programmer. ===Installering=== Hent og installer [[http://it.uib.no/?link_id=1530&sublink_id=2469&content_id=3726&modus=vis_seek_resultat&prodid=105 SSH]]. Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[https://bs.uib.no/?module=issues&action=new&gid=20 Brukerstøtte for IFT]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] 4a63aab97f9da360e6ae22b2fe1ef07c4ee7f3bc 1130 1129 2010-02-17T14:11:18Z Nfyku 4 wikitext text/x-wiki ==SSH innlogging fra Windows maskin til Unix maskin== SSH er en sikker og kryptert innlogging og kan benyttes både fra universitetets nettverk og fra Internett. Dette er en tekst-basert innlogging, og er kjapp og grei når man skal gjøre enkle ting, men man kan også kjøre noen større programmer som f.eks. maple og matlab (disse virker i både tekst mode og grafisk mode). Om du prøver å kjøre et grafisk (X) program, f.eks. xmaple eller xclock, vil du få en feilmelding som dette: [mikroserver2]$ matlab Error: Can’t open display: Bruk for eksempel WinX, [[http://sourceforge.net/projects/xming/ Xming]], [[http://www.tightvnc.com/ Tight VNC]] eller [[http://www.ii.uib.no/~bjorge/NX/ NX]] for kjøre grafiske programmer. ===Installering=== Hent og installer [[http://it.uib.no/?link_id=1530&sublink_id=2469&content_id=3726&modus=vis_seek_resultat&prodid=105 SSH]]. Etter installasjon har du to nye icon, på desktop, et SSH Secure Shell Client og et SSH Secure File Transfer (som brukes for overføring av filer mellom din pc og din unix-bruker). ===Login med SSH=== Bruk SSH Secure Shell Client iconet for å starte ssh, click Quick Connect, skriv inn mikroserver2.ift.uib.no (eller et annet servernavn) som Host Name og ditt Unix-brukernavn som User Name. (Port Number skal være 22.) Første gangen du ssh’er til en maskin (f.eks. mikroserver2), vil du få spørsmålet Do you want to save the new host key to the local database? Svar Yes Dersom du har ssh’et til maskinen tidligere, men nå får beskjed om at Host Identification has changed ! kan det være at maskinen har blitt oppgradert og dermed fått ny ssh-host-id (mest sannsynlig). Om maskinen ikke har blitt oppgradert – ta kontakt med [[https://bs.uib.no/?module=issues&action=new&gid=20 Brukerstøtte for IFT]]. Dersom ssh-host-id er ok, tast inn ditt passord og du vil få et shell på mikroserver2. ===Logout fra SSH=== Ikke avslutt ssh-vinduet slik du avslutter andre windows-program. For å unngå at det henger igjen prosesser på serveren, er det viktig at du bruker kommandoen logout eller tastekombinasjonen Ctrl-d i shell vinduet. Da vil du få beskjed og mulighet til å rydde opp i evtuelle prosesser som kjører i bakgrunnen. Når teksten i vindusrammen nede til venstre er Not connected – press Enter or Space to connect, kan du trygt avslutte/lukke vinduet. [[Category:Mikroelektronikk]] c4872729a69adbd5af8f836a02036689e410355f 0 283 1126 2010-02-17T10:44:42Z Nfyku 4 Created page with '==VNC-SSH innlogging== ===Forberedelser=== Start først opp din egen VNC server som forklart i VNC innlogging mot egen server. ===Opprette SSH tunnel=== ====Start opp SSH Secu...' wikitext text/x-wiki ==VNC-SSH innlogging== ===Forberedelser=== Start først opp din egen VNC server som forklart i VNC innlogging mot egen server. ===Opprette SSH tunnel=== ====Start opp SSH Secure Shell==== 1. velg Profiles → Add Profile… gi den et navn f.eks. mikroserver2 2. velg Profiles → Edit Profiles…, velg mikroserver2 blant profiles i venstre felt. 3. velg Tunneling tab 1. velg Outgoing tab 1. click Add… 2. skriv inn et navn i Display Name feltet, f.eks. mikroserver2 3. pass på at Type er TCP 4. skriv inn 5900 i feltet Listen Port 5. sjekk at Allow Local Connections Only er krysset av 6. skriv inn mikroserver2.ift.uib.no i Destination Host (adressen til maskinen du kjører VNC server på) 7. skriv inn summen av 5900 og ditt desktop nummer, eks 5906, i feltet Destination Port 8. click OK 4. click OK 5. velg Profiles → portal1 6. skriv inn portal1.ift.uib.no i Host name feltet 7. skriv inn ditt unix-brukernavn i User name feltet 8. Port number skal være 22 9. la resten være som det er. 10. velg Connect 11. tast inn ditt unix-bruker passord 12. legg ned / minimize SSH vinduet, det kjører nå SSH tunnellen og må kjøre så lenge du bruke VNC Viewer via SSH. 13. når du er ferdig og har avsluttet VNC Viewer, logger du først ut fra serveren med kommandoen logout og så lukker du SSH vinduet. ====Neste gang du skal opprette SSH tunnellen==== * start SSH Secure Shell * utfør punktene fra og med punkt 6 over. ===Problemer?=== Om du får melding om at SSH tunnell ikke kunne opprettes, sjekk om du kjører VNC-server på din pc, den kan skape problemer. Login til egen VNC-SSH server Start VNC Viewer og skriv inn localhost i Server feltet og click OK og tast inn ditt vnc passord. Logout fra egen VNC-SSH server Bruk samme fremgangsmåte som forklart under Metode 2 → Logout fra egen VNC server i VNC innlogging. [[Category:Mikroelektronikk]] 6fa7e6730264e056c51ce196732ac1f679801826 1127 1126 2010-02-17T13:33:14Z Nfyku 4 wikitext text/x-wiki ==VNC-SSH innlogging== ===Opprette SSH tunnel=== # Start opp SSH Secure Shell # Velg Profiles → Add Profile… gi den et navn f.eks. "mikroserver2 via portal1" # Velg Profiles → Edit Profiles…, velg mikroserver2 blant profiles i venstre felt. # Velg Tunneling tab # Velg Outgoing tab ## Klikk Add… ## Skriv inn et navn i Display Name feltet, f.eks. mikroserver2 ## Pass på at Type er TCP ## Skriv inn 5900 i feltet Listen Port ## Sjekk at Allow Local Connections Only er krysset av ## Skriv inn mikroserver2.ift.uib.no i Destination Host (adressen til maskinen du kjører VNC server på) ## Skriv inn summen av 5900 og ditt desktop nummer, eks 5906, i feltet Destination Port ## Klikk OK # Velg Conection tab # Skriv inn portal1.ift.uib.no i Host name feltet # Skriv inn ditt unix-brukernavn i User name feltet # Port number skal være 22 # la resten være som det er. # Klikk OK (ferdig med konfigurasjon) # Velg Profiles -> "mikroserver2 via portal1" # Tast inn ditt unix-bruker passord # Legg ned / minimize SSH vinduet, det kjører nå SSH tunnellen og må kjøre så lenge du bruke VNC Viewer via SSH. # Når du er ferdig og har avsluttet VNC Viewer, logger du først ut fra serveren med kommandoen logout og så lukker du SSH vinduet. ====Neste gang du skal opprette SSH tunnellen==== # Start SSH Secure Shell # Utfør punktene fra og med punkt 6 over. ===Login til VNC-SSH server=== Start først opp din egen VNC server som forklart i VNC innlogging mot egen server, eller bruk en eksisternde VNC server. Start VNC Viewer og skriv inn localhost (ikke :port) i Server feltet og click OK og tast inn ditt vnc passord. ===Logout fra egen VNC-SSH server=== Bruk samme fremgangsmåte som forklart under Metode 2 → Logout fra egen VNC server i VNC innlogging. ===Problemer?=== Om du får melding om at SSH tunnell ikke kunne opprettes, sjekk om du kjører VNC-server på din pc, den kan skape problemer. [[Category:Mikroelektronikk]] cc36fa21f1cd7ba2df6d9376b9d239ee4e54af91 1128 1127 2010-02-17T13:34:22Z Nfyku 4 wikitext text/x-wiki ==VNC-SSH innlogging== ===Opprette SSH tunnel=== # Start opp SSH Secure Shell # Velg Profiles → Add Profile… gi den et navn f.eks. "mikroserver2 via portal1" # Velg Profiles → Edit Profiles…, velg mikroserver2 blant profiles i venstre felt. # Velg Tunneling tab # Velg Outgoing tab ## Klikk Add… ## Skriv inn et navn i Display Name feltet, f.eks. mikroserver2 ## Pass på at Type er TCP ## Skriv inn 5900 i feltet Listen Port ## Sjekk at Allow Local Connections Only er krysset av ## Skriv inn mikroserver2.ift.uib.no i Destination Host (adressen til maskinen du kjører VNC server på) ## Skriv inn summen av 5900 og ditt desktop nummer, eks 5906, i feltet Destination Port ## Klikk OK # Velg Conection tab ## Skriv inn portal1.ift.uib.no i Host name feltet ## Skriv inn ditt unix-brukernavn i User name feltet ## Port number skal være 22 ## la resten være som det er. ## Klikk OK (ferdig med konfigurasjon) # Velg Profiles -> "mikroserver2 via portal1" # Tast inn ditt unix-bruker passord # Legg ned / minimize SSH vinduet, det kjører nå SSH tunnellen og må kjøre så lenge du bruke VNC Viewer via SSH. # Når du er ferdig og har avsluttet VNC Viewer, logger du først ut fra serveren med kommandoen logout og så lukker du SSH vinduet. ====Neste gang du skal opprette SSH tunnellen==== # Start SSH Secure Shell # Utfør punktene fra og med punkt 7 over. ===Login til VNC-SSH server=== Start først opp din egen VNC server som forklart i VNC innlogging mot egen server, eller bruk en eksisternde VNC server. Start VNC Viewer og skriv inn localhost (ikke :port) i Server feltet og click OK og tast inn ditt vnc passord. ===Logout fra egen VNC-SSH server=== Bruk samme fremgangsmåte som forklart under Metode 2 → Logout fra egen VNC server i VNC innlogging. ===Problemer?=== Om du får melding om at SSH tunnell ikke kunne opprettes, sjekk om du kjører VNC-server på din pc, den kan skape problemer. [[Category:Mikroelektronikk]] d0b9b10eb462a71dc65f0226324bdbe4973fa217 0 36 1131 1101 2010-02-17T19:48:06Z Ave082 33 null er ikke syntetiserbar i precision, clk=1 and clk'last_value=0 syntetiseres slik at den trigger under hele den høye pulsen, enable_in må være høy for at en skal få noe ut wikitext text/x-wiki ===Synthesisering av vhdl kode=== Grunnen til at vi skal synthesisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignale frå den sythisierte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== <pre> mentor precision </pre> Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone III med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: <pre> setenv QUARTUS_ROOTDIR /prog/altera/altera9.1/quartus </pre> ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii </pre> Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: <pre> test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; </pre> Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: <pre> vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo </pre> Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 38f27ef41e3c9e3602e1d586da251ac6fa54ae44 0 28 1138 1082 2010-02-18T14:03:41Z Nfyku 4 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. <pre> ssh -X mikroserver2 /prog/design_kits/micro.init.csh </pre> ==Starte opp IC studio== Skriv i et terminalvindu: <pre> xset +fp tcp/mikroserver2:7100 # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & </pre> Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. Om du ønsker å bruke Mentor programmene fra en Windows-PC så se på forklaringene i [[Teknisk hjelp]] ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: <pre> firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html </pre> Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: <pre> acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf </pre> ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". [[Category:Mikroelektronikk]] fd9d45ffcb23dc37414c226e5a6e492fd8be0802 0 137 1140 1061 2010-02-19T16:18:30Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] === Job openings in our group=== There is a postdoc position in our group open, watch these pages from a link to the application. More info below. There will be more positions (PhD) in the near future. * [[Post doc, spring 2010, see the link| http://web.ift.uib.no/~lipniack/jobs/bergen_16.02.10.pdf]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 3d0206c3fe31b2f50b893aa1ca135fdb76f71535 0 285 1141 2010-02-19T16:20:52Z Nfyal 26 Created page with 'Postdoctoral Research Fellowship/Researcher position (Experimental Particle Physics) POSITION AS POSTDOCTORAL RESEARCH FELLOW / RESEARCHER - Experimental Particle Physics in AT...' wikitext text/x-wiki Postdoctoral Research Fellowship/Researcher position (Experimental Particle Physics) POSITION AS POSTDOCTORAL RESEARCH FELLOW / RESEARCHER - Experimental Particle Physics in ATLAS experiment at the Large Hadron Collider (LHC) is available at The Department of Physics and Technology (www.ift.uib.no), University of Bergen, in the Faculty of Mathematics and Natural Sciences. The position is funded by The Research Council of Norway under the project CERN-Related High Energy Particle Physics Research. The selected post-doc or researcher fellow is expected to work within ATLAS which is one of the experiments at CERN's "Large Hadron Collider" (LHC), and analyze the first ultra-Tev high energy collisions data to be collected starting in 2010. Present research group's activities in ATLAS include: -monitoring of the Inner Detector (ID) silicon detector system and developement of related detector-specific software -Physics analysis related to o extra symmetries (supersymmetry) o symmetry breaking (Higgs boson(s)) o top quarks and tau leptons o Black hole production o model-independent searches for new physics with mu+mu-, mu+- mu+ mu- and mu+ mu- mu+ mu- final states o detector validation studies with Z-> mu+mu-, Upsilon -> mu+ mu- and J/psi -> mu+ mu- - popularization activities (Outreach) The selected candidate is expected to be strongly analysis oriented and analyze the first data to be collected by the ATLAS detector. S/He will also take some responsibility for the operation of the Inner Detector (ID) in general and the Semi Conductor Tracker (SCT) in particular. The candidate should have or soon expected to receive PhD in particle physics. The successful candidate should have a solid background in experimental particle physics. Experience in analysis of experimental data is an advantage. The candidate will strongly interact with Master and PhD-students and post-doctoral researchers in the group, thus, collaborative abilities are also important. See also: http://www.uib.no/ift/en https://wikihost.uib.no/ift/index.php/Particle_Physics_group http://koherens.uio.no/hep/hepp/ Interested candidates have to contact Prof. Anna Lipniacka, anna.lipniacka@ift.uib.no concerning the details of the application procedure via https://secure.jobbnorge.no/search.aspx . Pay Grade: 57-60 (approx. NOK 438 000 -463 000 per year). The position is available for a period of 2 years, with possibility for up to 2 years extension. Closing date for applications: April 15, 2010 Starting date is preferably May 1st 2010. 93441532edbb7840019d8546a9cc6d7914d04398 0 105 1146 1074 2010-02-23T12:08:17Z Nfyku 4 wikitext text/x-wiki [http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow] [http://vlsi.ee.hacettepe.edu.tr/tutorials/tutorial_yildirim/tutorial.htm ASIC Design Flow Tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_1.pdf Design arcithect tutorial] [[http://www.ece.unh.edu/courses/ece711/tutorials/ Expedition PCB and accompanying tools]] [http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_2.pdf IC studio tutorial] [http://www.swarthmore.edu/NatSci/tali/E77/Mentor_Tutorials/tutorials.htm Mentor Graphic Tutorials] [http://people.ee.duke.edu/~jmorizio/ece261/LABMANUALS/ Mentor tutorials relativt oppdaterte] [http://www.ele.uri.edu/Research/cherry/mentor_tutorial/index.html Mentor Graphics IC Layout & Verification Tutorial] [http://pages.cs.wisc.edu/~david/courses/cs755/cs755/ VLSI System Design course with tutorials] [[Category:Mikroelektronikk]] 58243623845bfe33603e8e0f0ff94558e696aef7 1147 1146 2010-02-23T12:08:41Z Nfyku 4 wikitext text/x-wiki [http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow] [http://vlsi.ee.hacettepe.edu.tr/tutorials/tutorial_yildirim/tutorial.htm ASIC Design Flow Tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_1.pdf Design arcithect tutorial] [http://www.ece.unh.edu/courses/ece711/tutorials/ Expedition PCB and accompanying tools]] [http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_2.pdf IC studio tutorial] [http://www.swarthmore.edu/NatSci/tali/E77/Mentor_Tutorials/tutorials.htm Mentor Graphic Tutorials] [http://people.ee.duke.edu/~jmorizio/ece261/LABMANUALS/ Mentor tutorials relativt oppdaterte] [http://www.ele.uri.edu/Research/cherry/mentor_tutorial/index.html Mentor Graphics IC Layout & Verification Tutorial] [http://pages.cs.wisc.edu/~david/courses/cs755/cs755/ VLSI System Design course with tutorials] [[Category:Mikroelektronikk]] 0ab38b22d14edd1e6efb7205261cab963af3ac99 1155 1147 2010-02-24T10:23:35Z Nfyku 4 wikitext text/x-wiki [http://asic.austriamicrosystems.com/hitkit/hk370/icstation/index.html AMS IC Station Layout &Verification Flow] [http://vlsi.ee.hacettepe.edu.tr/tutorials/tutorial_yildirim/tutorial.htm ASIC Design Flow Tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_1.pdf Design arcithect tutorial] [http://vader.ece.ucsb.edu/ece189/Mentor2007/ DxDesigner/ExpeditionPCB Tutorials] [http://www.ece.unh.edu/courses/ece711/tutorials/ Expedition PCB and accompanying tools]] [http://www.engr.uky.edu/~ee564/tutorials/ic.htm IC Station tutorial] [http://csserver.evansville.edu/~mr56/ece755/tutorial_2.pdf IC studio tutorial] [http://www.swarthmore.edu/NatSci/tali/E77/Mentor_Tutorials/tutorials.htm Mentor Graphic Tutorials] [http://people.ee.duke.edu/~jmorizio/ece261/LABMANUALS/ Mentor tutorials relativt oppdaterte] [http://www.ele.uri.edu/Research/cherry/mentor_tutorial/index.html Mentor Graphics IC Layout & Verification Tutorial] [http://pages.cs.wisc.edu/~david/courses/cs755/cs755/ VLSI System Design course with tutorials] [[Category:Mikroelektronikk]] 8299c8397eb00f798d97942d4b9d95d0491ea7dc 0 32 1148 64 2010-02-23T12:28:23Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable setenv SDD_ROOT /prog/mentor/ee2007.7/2007.7EE/ setenv MGC_HOME /prog/mentor/ee2007.7/2007.7EE/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/ee2007.7/2007.7EE/SDD_HOME ==Starte utleggsprogrammet== /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/ExpeditionPCB ==Skjemategning== Vi kan bruke Design Architect eller DX designer [[Category:Mikroelektronikk]] b1dd8b1f2647c1d29174f4913494da136e1acaae 1149 1148 2010-02-23T13:45:52Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable setenv SDD_ROOT /prog/mentor/ee2007.7/2007.7EE/ setenv MGC_HOME /prog/mentor/ee2007.7/2007.7EE/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/ee2007.7/2007.7EE/SDD_HOME ==Starte utleggsprogrammet== /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/ExpeditionPCB ==Skjemategning== Vi kan bruke Design Architect eller DX designer ==Introduksjon== [Expedition PCB introduction] [[Category:Mikroelektronikk]] 75f92a3d91b0244881f93987a693107aff378411 1150 1149 2010-02-23T13:46:16Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable setenv SDD_ROOT /prog/mentor/ee2007.7/2007.7EE/ setenv MGC_HOME /prog/mentor/ee2007.7/2007.7EE/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/ee2007.7/2007.7EE/SDD_HOME ==Starte utleggsprogrammet== /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/ExpeditionPCB ==Skjemategning== Vi kan bruke Design Architect eller DX designer ==Introduksjon== [[Expedition PCB introduction]] [[Category:Mikroelektronikk]] 462eaecf11aea0de5cb5806a5fb7155ee40f8f3d 0 286 1151 2010-02-23T13:52:11Z Nfyku 4 Created page with ' == EXPEDITION PCB INTRODUCTION == IS DESIGNED TO TEACH YOU THE BASIC WORKFLOW FOR CREATING A SIMPLE PRINTED CIRCUIT BOARD USING THE MENTOR GRAPHICS EXPEDITION PCB TOOL. YOU WILL...' wikitext text/x-wiki == EXPEDITION PCB INTRODUCTION == IS DESIGNED TO TEACH YOU THE BASIC WORKFLOW FOR CREATING A SIMPLE PRINTED CIRCUIT BOARD USING THE MENTOR GRAPHICS EXPEDITION PCB TOOL. YOU WILL BE LOOKING AT EDITOR ENVIRONMENTS AND FUNDAMENTAL LIBRARY CONCEPTS. YOU WILL LEARN HOW TO CREATE PADSTACKS AND CELLS. YOU WILL EVENTUALLY ASSEMBLE DATABASES FOR CREATING PARTS. COMPUTER FILES ARE SUPPLIED FOR THE LAB WHERE NECESSARY. ===Schedule=== Lab 1 (4 hours) * INTRODUCTION TO EXPEDITION PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==PART 1 PADSTACK DEFINITION== # open the “library manager” and create a new library called “lab1” under directory “c:\mgtraining\lab1\”. # click on the “edit” menu and select “partition editor”. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. # under “setup” select “parameter setup”. See that under “general” nothing is declared, but under “vias” there is only one standard padstack declared called “L: 026 VIA”. Select “close”. # select the button “library services” from the “library manager”. Select “padstack” menu and select with the browser for the “input from” to “c:\mgtraining\common\libraries\master\master.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the “library manager” the button “Padstacks (pads & holes)”. You should have now two padstack declarations under menu “padstacks” from the padstack editor. Examine the properties of both padstack declarations by clicking once on them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. # exercise: Create a padstack definition for the through hole via with min. 250 um and pad min. 450 um (use the documentation from Electrotryck, p.22) (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) Summary: you now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== # You should have the “lab1” Library open in the Library Manager. <Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: Body length = 5 Body width = 3 Pin to pin spacing = 1.27 Row to row spacing = 5.2 Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: Columns: 4 Spacing: 100 Rows: 2 Spacing: 300 Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== # You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== # You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: In1 2 In2 3 VCC 6 GND 7 Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== # You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 41806eb6bf7e39dabdd5bba6adf9b042acd79ee4 1152 1151 2010-02-23T13:58:44Z Nfyku 4 wikitext text/x-wiki == EXPEDITION PCB INTRODUCTION == IS DESIGNED TO TEACH YOU THE BASIC WORKFLOW FOR CREATING A SIMPLE PRINTED CIRCUIT BOARD USING THE MENTOR GRAPHICS EXPEDITION PCB TOOL. YOU WILL BE LOOKING AT EDITOR ENVIRONMENTS AND FUNDAMENTAL LIBRARY CONCEPTS. YOU WILL LEARN HOW TO CREATE PADSTACKS AND CELLS. YOU WILL EVENTUALLY ASSEMBLE DATABASES FOR CREATING PARTS. COMPUTER FILES ARE SUPPLIED FOR THE LAB WHERE NECESSARY. ===Schedule=== Lab 1 (4 hours) * INTRODUCTION TO EXPEDITION PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==PART 1 PADSTACK DEFINITION== # open the “library manager” and create a new library called “lab1” under directory “c:\mgtraining\lab1\”. # click on the “edit” menu and select “partition editor”. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. # under “setup” select “parameter setup”. See that under “general” nothing is declared, but under “vias” there is only one standard padstack declared called “L: 026 VIA”. Select “close”. # select the button “library services” from the “library manager”. Select “padstack” menu and select with the browser for the “input from” to “c:\mgtraining\common\libraries\master\master.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the “library manager” the button “Padstacks (pads & holes)”. You should have now two padstack declarations under menu “padstacks” from the padstack editor. Examine the properties of both padstack declarations by clicking once on them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. # exercise: Create a padstack definition for the through hole via with min. 250 um and pad min. 450 um (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) Summary: you now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. #<Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: Body length = 5 Body width = 3 Pin to pin spacing = 1.27 Row to row spacing = 5.2 Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: Columns: 4 Spacing: 100 Rows: 2 Spacing: 300 Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: In1 2 In2 3 VCC 6 GND 7 Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 26ae429a078fb53aec7db9e2ba88db4c5b321a56 1153 1152 2010-02-23T14:06:35Z Nfyku 4 wikitext text/x-wiki == EXPEDITION PCB INTRODUCTION == IS DESIGNED TO TEACH YOU THE BASIC WORKFLOW FOR CREATING A SIMPLE PRINTED CIRCUIT BOARD USING THE MENTOR GRAPHICS EXPEDITION PCB TOOL. YOU WILL BE LOOKING AT EDITOR ENVIRONMENTS AND FUNDAMENTAL LIBRARY CONCEPTS. YOU WILL LEARN HOW TO CREATE PADSTACKS AND CELLS. YOU WILL EVENTUALLY ASSEMBLE DATABASES FOR CREATING PARTS. COMPUTER FILES ARE SUPPLIED FOR THE LAB WHERE NECESSARY. ===Schedule=== Lab 1 (4 hours) * INTRODUCTION TO EXPEDITION PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==PART 1 PADSTACK DEFINITION== # open the “library manager” and create a new library called “lab1” under directory “c:\mgtraining\lab1\”. # click on the “edit” menu and select “partition editor”. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. # under “setup” select “parameter setup”. See that under “general” nothing is declared, but under “vias” there is only one standard padstack declared called “L: 026 VIA”. Select “close”. # select the button “library services” from the “library manager”. Select “padstack” menu and select with the browser for the “input from” to “c:\mgtraining\common\libraries\master\master.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the “library manager” the button “Padstacks (pads & holes)”. You should have now two padstack declarations under menu “padstacks” from the padstack editor. Examine the properties of both padstack declarations by clicking once on them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. # exercise: Create a padstack definition for the through hole via with min. 250 um and pad min. 450 um (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) Summary: you now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. #<Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 32345dc7b59f58fe478573ae850c8a6acde6cbea 1154 1153 2010-02-23T14:09:06Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * INTRODUCTION TO EXPEDITION PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==PART 1 PADSTACK DEFINITION== # open the “library manager” and create a new library called “lab1” under directory “c:\mgtraining\lab1\”. # click on the “edit” menu and select “partition editor”. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. # under “setup” select “parameter setup”. See that under “general” nothing is declared, but under “vias” there is only one standard padstack declared called “L: 026 VIA”. Select “close”. # select the button “library services” from the “library manager”. Select “padstack” menu and select with the browser for the “input from” to “c:\mgtraining\common\libraries\master\master.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the “library manager” the button “Padstacks (pads & holes)”. You should have now two padstack declarations under menu “padstacks” from the padstack editor. Examine the properties of both padstack declarations by clicking once on them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. # exercise: Create a padstack definition for the through hole via with min. 250 um and pad min. 450 um (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) Summary: you now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. #<Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] de8d05c9a6474c114753200f6c5fd63045438d00 1156 1154 2010-02-24T10:52:56Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * INTRODUCTION TO EXPEDITION PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “library manager” and create a new library called “lab1” under directory “c:\mgtraining\lab1\”. # Click on the “edit” menu and select “partition editor”. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. # Under “setup” select “parameter setup”. See that under “general” nothing is declared, but under “vias” there is only one standard padstack declared called “L: 026 VIA”. Select “close”. # Select the button “library services” from the “library manager”. Select “padstack” menu and select with the browser for the “input from” to “c:\mgtraining\common\libraries\master\master.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the “library manager” the button “Padstacks (pads & holes)”. You should have now two padstack declarations under menu “padstacks” from the padstack editor. Examine the properties of both padstack declarations by clicking once on them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. # Exercise: Create a padstack definition for the through hole via with min. 250 um and pad min. 450 um (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) Summary: you now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. #<Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 733de52f7e2404a1d9a39102268e4c3ff57a92bd 1157 1156 2010-02-24T13:16:30Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “library manager” and create a new library for example under directory $HOME/kurs. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the “library manager” the button “Padstacks (pads & holes)”. You should have now two padstack declarations under menu “padstacks” from the padstack editor. Examine the properties of both padstack declarations by clicking once on them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. # Exercise: Create a padstack definition for the through hole via with min. 250 um and pad min. 450 um (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) Summary: you now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. #<Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 4e6f3cd15cd4ddbd2706bb7477efe81c21b45a05 1158 1157 2010-02-24T13:20:56Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “library manager” and create a new library for example under directory $HOME/kurs. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ---- Exercise: Create a padstack definition for the through hole via with min. 250 um and pad min. 450 um (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) Summary: you now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. #<Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 2efd51207187d7e80010ce1b2c94c782c7e482a2 1159 1158 2010-02-24T13:26:20Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “library manager” and create a new library for example under directory $HOME/kurs. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. #<Click> the Cells (Package, Draft & Mechanical) button to enter the Cell Editor. # On the Cell Editor dialog, create a new “Partition” called “amplifiers”. # <Click> the New Cell button. # Select the Create new cell option (at the top of the dialog). # Enter the Cell name 8SO. # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 68d939d1a9f14bea52061c073bc7ce3b898f0fee 0 286 1160 1159 2010-02-24T13:49:17Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # <Click> the Cell Properties button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button. # On the Place Pins dialog, <click> the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] f7773f5d899ba7cd5213909a1341baf1573047ed 1161 1160 2010-02-24T14:00:52Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialog, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # <Click> the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # On the main Cell Editor dialog, <click> the Apply button to save your work. Examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] e2850b3aea0f442dd46f7ece0614982b1f1d463b 1162 1161 2010-02-24T14:07:52Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialog, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # <Click> the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # <Click> the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Editor Control dialog, <click> the OK button. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] aff3bb9c72a454eb04629584303ee4898d5ef151 1163 1162 2010-02-24T15:00:54Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” padstack. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the “IPC, SOIC” padstack will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialog, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click>the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 04da19407b46afd2bc88ca94cc7c1891e0c31072 1164 1163 2010-02-24T15:31:45Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialog, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click>the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # <Click> the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, <click> the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup>Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 14, and choose the through via example padstack (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # <Click> the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # <Click> the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. <Click> directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] ae2f076ad252ee49a71848876cd05dce0f81b106 1165 1164 2010-02-25T07:51:48Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialog, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click>the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool at the bottom of the window, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then <click-drag> the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] a3e8fc32d77f9e570b0b5f38a3a8abd713964695 1166 1165 2010-02-25T08:09:54Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialog, <click> the Close button. # On the Create Package Cell dialog, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialog, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click>the Close button on the Place Pins dialog. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialog, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. # <Click> the OK button on the main Cell Editor dialog to save and exit the Cell Editor. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # <click> the button “Symbols (Circuit&Logical)”. # <click> “file” -> “new library”: create a new partition “amplifiers”. # <click> “file” -> “new symbol”: create a new symbol “amp215”. (A graphical editor should pop-up.) # examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “design Capture Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 50f53a940759daa500a3559a0467bd49e952471e 1167 1166 2010-02-25T08:19:12Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] f756725e58f951b245e394ddf3e1cade7be59e60 1168 1167 2010-02-25T08:36:50Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.)[[File:amp215_symbol.png]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 64d2ddd8a6636770bc493f827d3b48d6b1d69a2f 1170 1168 2010-02-25T08:41:38Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) [[Image:amp215_symbol.png|400px|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] d8d33c6ac4d95f2927fe3f46d818e0fc181899fa 1172 1170 2010-02-25T08:52:17Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. (You can ignore the warnings.) [[Image:amp215_symbol.png|centre|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # <Click> the Parts Database button to launch the PartsDB Editor. # On the PartsDB Editor dialog, creatre the Partition “ amplifiers”. # <Click> the New button to start a new PDB entry. Change the Number to Opamp1. Change the Name to amp01. Change the Label to amp01A. # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, a single amplifier packaged. # Specify a Reference des prefix of U. # On the PartsDB Editor dialog, <click> the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), <click> the Import button. # On the Import dialog, select the symbol name amp215 from the list. # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # <Click> the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] d82629a290eb9b3fb5be0e7afd6f1fee6fead9dd 1173 1172 2010-02-25T09:07:43Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Symbols" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. [[Image:amp215_symbol.png|centre|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Parts" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Parts" folder in the Library Navigator Tree. # Create a new “Part” called “amp01”. (The Part Editor dialogue should pop-up.) # Change the Number to "Opamp1". Change the Label to "amp01A". # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, "A single amplifier packaged". # Specify a Reference des prefix of "U". # On the Part Editor dialog, click the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), click the Import button. # On the Import dialog, select the symbol name amp215 from the list (select "amplifiers" from the Central Library, and then the Symbol name). # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # Click the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # <Click> the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # <Click> the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] 4e2a6220e34d5b8ee63cb9a552d9ff7fa2308e18 1174 1173 2010-02-25T09:15:11Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. Computer files are supplied for the lab where necessary. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Symbols" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. [[Image:amp215_symbol.png|centre|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Parts" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Parts" folder in the Library Navigator Tree. # Create a new “Part” called “amp01”. (The Part Editor dialogue should pop-up.) # Change the Number to "Opamp1". Change the Label to "amp01A". # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, "A single amplifier packaged". # Specify a Reference des prefix of "U". # On the Part Editor dialog, click the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), click the Import button. # On the Import dialog, select the symbol name amp215 from the list (select "amplifiers" from the Central Library, and then the Symbol name). # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # Click the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # Click the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # Click the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # <Click> the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the PartsDB Editor. [[Image:amp1_pin_mapping.png|centre|Pin mapping dialogue the OpAmp]] ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # <click> button “layout templates”. # <click> once on the “4 layer Template” and press the “copy template” button above. # <click> once on the copied template and give it the name “lab1 template”. # <click> once on the “edit template” button. Ignore the forward and backward annotation warnings by pressing “OK”. A default template is opened in “Expedition PCB”. # <click> once on the menu “setup” and select “setup parameters”. # In the menu “general” set the “number of physical layers” to 6. “display units” should be set to “microns” and “meters/s”. <click> on “apply”. # In the menu “Layer Stackup” change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “close”. # “Save” the template and “exit”. # In the “layout template” select “close”. # Select in the “file manger” file -> “exit”. [[Category:Mikroelektronikk]] a0734ceee7c839839e3cef6e3d0d20563ed5741e 1176 1174 2010-02-25T09:28:54Z Nfyku 4 wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Symbols" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. [[Image:amp215_symbol.png|centre|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Parts" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Parts" folder in the Library Navigator Tree. # Create a new “Part” called “amp01”. (The Part Editor dialogue should pop-up.) # Change the Number to "Opamp1". Change the Label to "amp01A". # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, "A single amplifier packaged". # Specify a Reference des prefix of "U". # On the Part Editor dialog, click the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), click the Import button. # On the Import dialog, select the symbol name amp215 from the list (select "amplifiers" from the Central Library, and then the Symbol name). # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # Click the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # Click the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # Click the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # Click the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the Part Editor. [[Image:amp1_pin_mapping.png|centre|Pin mapping dialogue the OpAmp]] ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # Click button “layout templates”. # Click once on the “4 layer Template” and press the “copy template” button above. # Click once on the copied template and give it the name “lab1 template”. # Click once on the “edit template” button. A default template is opened in “Expedition PCB”. # Click on the menu “Setup>Setup Parameters”. # In the “General” tap set the “number of physical layers” to 6. “Display units” should be set to “microns” and “meters/s”. Click on “Apply”. # In the “Layer Stackup” tab change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “OK”. # “Save” the template and “exit”. [[Category:Mikroelektronikk]] ba76be99fefc9757b79d99ec1d6d2ce82ebab987 6 288 1169 2010-02-25T08:38:09Z Nfyku 4 Opamp symbol for Expedition PCB Introduction wikitext text/x-wiki Opamp symbol for Expedition PCB Introduction 4f378eee9523d216f05b71d73d966519611ea5a7 1171 1169 2010-02-25T08:50:18Z Nfyku 4 uploaded a new version of "[[File:Amp215 symbol.png]]" wikitext text/x-wiki Opamp symbol for Expedition PCB Introduction 4f378eee9523d216f05b71d73d966519611ea5a7 6 289 1175 2010-02-25T09:16:05Z Nfyku 4 Pin mapping diaglogue box for the Expedition PCB introduction wikitext text/x-wiki Pin mapping diaglogue box for the Expedition PCB introduction 85a4edf56a707d5dbb1320c07bc905b49d2f10a6 0 32 1177 1150 2010-02-25T09:47:04Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable setenv SDD_ROOT /prog/mentor/ee2007.7/2007.7EE/ setenv MGC_HOME /prog/mentor/ee2007.7/2007.7EE/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/ee2007.7/2007.7EE/SDD_HOME ==Starte utleggsprogrammet== /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/ExpeditionPCB ==Skjemategning== Vi kan bruke Design Architect eller DX designer ==Introduksjon== [[Expedition PCB introduction]] [[Expedition PCB design capture]] [[Category:Mikroelektronikk]] 2b8e951b5514321b7d40e5401e2b715dbcd23a13 1180 1177 2010-02-25T10:12:05Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== En veiledning til design og utlegg Dette er en kort beskrivelse av hvordan man bruker Expedition PCB Sette opp miljøvariable setenv SDD_ROOT /prog/mentor/ee2007.7/2007.7EE/ setenv MGC_HOME /prog/mentor/ee2007.7/2007.7EE/MGC_HOME.ixl setenv SDD_HOME /prog/mentor/ee2007.7/2007.7EE/SDD_HOME ==Starte utleggsprogrammet== /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/ExpeditionPCB ==Skjemategning== Vi kan bruke Design Architect eller DX designer ==Introduksjon== These walk-throughs started from [http://www.ict.kth.se/courses/IL2208/ Department of electronics, computer and software Systems, KTH, Sweden] [[Expedition PCB introduction]] [[Expedition PCB design capture]] [[Category:Mikroelektronikk]] 5af70120df368130d7289cbbece5e9b7965c1f0b 1183 1180 2010-02-26T09:26:46Z Nfyku 4 wikitext text/x-wiki ===Kom igang med Expedition PCB=== Start the Expedition Enterprise Flow Dashboard by expedition These walk-throughs started from [http://www.ict.kth.se/courses/IL2208/ Department of electronics, computer and software Systems, KTH, Sweden] [[Expedition PCB introduction]] [[Expedition PCB design capture]] [[Category:Mikroelektronikk]] d93bc05a33c82182e6fd88e55b11540f4a60350f 0 290 1178 2010-02-25T09:57:15Z Nfyku 4 Created page with 'The purpose of this lab is to practice the operation of PCB design capture and draw a basic schematic. ==Introduction== There are certain important files that you will be famili...' wikitext text/x-wiki The purpose of this lab is to practice the operation of PCB design capture and draw a basic schematic. ==Introduction== There are certain important files that you will be familiar with before the end of this course: filename.prj - the project file, which contains “pointers” to the locations of other files or folders that have projectrelated information, such as symbol libraries or configuration files. filename.sbk - the schematic block file, which contains graphical schematic data. foldername.cdb - the Common Data Base folder (CDB). The CDB is the compiled version of the schematic, and is the interim data base between DC and downstream tools such as Expedition PCB. Filename.lmc – the LibraryManager Catalogue file. This is the file that holds information about which symbol, cell, and PDB partitions reside in the Central Library. filename.slb - the symbol partition files where schematic symbols representing logic functions are stored within the Central Library. filename.pdb – the Part Database partition files where device information is stored within the Central Library. filename.cel – the Cell partition files where “footprint” information is stored within the Central Library. There are several processes and tools that you will become familiar with: Design Capture - the processes used during schematic design creation. The Verify tool – used to check your design for incorrect information or design mistakes. Compile CDB - the process that compiles the design into the Common Data Base. Packager - the process that will check the CDB to make sure it has all the relevant data, and then, if required, assign “packaging information,” such as Reference designators and pin numbers, in order to prepare the design for Expedition PCB. CDB to BOM – the Bill Of Materials Generator utility. Used to build the bill of materials after the packager has completed. Cross Reference – the utility that assigns page connector annotation information to off-page connector symbols in the schematic file. Connections – used to generate netlists. ==Part 1 PREPARATION== The purpose of this lab exercise is to familiarize yourself with the location of the data that you will be using for this class, and to set up some configuration files for use later in the class. Down the lab material from the website. Unzip the lab2.zip file to c:\mgtraining, # Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & # Browse to C:\Mgtraining. There are two folders, one named common and the other named project. # Open the project folder. There is a completed project called example. Open it and look at the contents. # Go back up to the Mgtraining folder and then down into the common folder and examine the contents. Note: Normally, the objects that we have included here in the common folder would be on a server on your network. You may have a similar setup or may have a slightly different approach. # Open the Libraries folder, and then the Master folder. This is the Central Library we will be using for the rest of the class. Notice the three files –Master.lmc,SysIndex.cbf, and CentLib.prp. These are files that are important to the way the Library Manager works.Look at the contents of the SymbolLibs, PartsDBLibs ,and CellDBLibs folders. The files in each of the folders are library object partitions. # Browse to the software load directory on this machine: C:\mentor\2000.5 \VBDC\config\vbdc # Copy cdb2bom.asc and crossref.asc from here into the C:\Mgtraining\common\config folder. We will examine the contents of these files and edit them later in the class. # Return to the C:\Mgtraining\common folder. Make anew folder under the common folder. Name the new folder Seed_Projects. You are going to create a seed project in this location later in this class. ==Part 2.Creat a seed project== The purpose of this lab exercise is to guide you through the process of creating projects. At the end of this lab, you will have created two new projects. The first is a “seed” project. It will be created by using the Project >> New command, and then the appropriate project settings will be made. The second project will be created from the seed project, using the Project >> Copy command. The second project will be used for the rest of the exercises in this class. Create the Seed Project: Note: In “real life” the seed projects may already be created for you – in this class we will create a new seed project in order to illustrate the process. # Launch DC using Start >> Programs >> Mentor Graphics WG2000.5 >> Design Capture >> Design Capture. # Select the Project >> New command. # In the Project Location field of the New Project Wizard, browse to the folder C:\mgtraining\common\seed_projects using the browse button to the right of the field. click the OK button once you have selected the Seed folder. # In the Project Name field, type in the project name seed1, then click on the Next button on the diaglogue. # We will not add any design files to this seed project, so click on the Next button at the bottom of the diaglogue. # Examine the Project Summary, and then click on the Finish button. # Notice that the seed project you have just created is automatically the active project in DC (see the name of the project in the Titlebar at the top of the Design Capture window). # Select the Project >> Settings pulldown menu. # On the Central Library Tab, select the Browse button beside the Central Library field. Browse to the library: C:\mgtraining\common\libraries\master \master.lmc # Select the File Locations tab on the diaglogue. Change the Configuration file type to Project Options. Click in the field that shows the path to the current config file and click on the Browse button. Browse to: C:\mgtraining\common\config\vbdcsys_C_seed .asc This config file was placed here for you by the system administrator for this class. Editing the project file to point to this config file, as you have just done, will cause the system to use this customized configuration file for any subsequent project that uses this seed project as a template. # click the Edit File button on the diaglogue. Look down through the config file to get an idea of what kinds of settings can be made in this file, but don’t change anything. When you are finished, close the config file. # Click the OK button on the diaglogue. # Select the Project >> PCB Integration pulldown menu. Uncheck the checkbox labeled Forward annotation. This will prevent anyone from reading this design into Expedition PCB before we are ready to release the project to board layout. # Next, check the checkbox labeled Packaging so that no one can accidentally run the packager in Repackage All mode (unless and until you uncheck this box). # Make sure the checkbox labeled Back annotation is checked (on), and the option to Generate FLATNETNAME properties is based on Schematic Net Name changes. # Click the OK button on the diaglogue. You now have a seed project that can be used as a “template” for starting any other job that will require the same project settings. Remember that at most work environments, the seed project will be located at a shared point on the network so that everyone can access it. ==Part 3 Create a project from the seed project== Create the class project: # Select the Project >> Copy command. # In the Old Project field, make sure the current project is listed as: C:\mgtraining\common\seed_projects\seed1 \seed1.prj # In the Project Name field, type in a project name of 2101A (you do not have to type in the .prj extension - in fact, it won’t let you). # In the Project Location field, type in the following pathname: C:\mgtraining\project\2101A. Click on the OK button on the diaglogue. # At this point, the new project has been created, but it is not the active project. Select the Project >> Open command, and browse to the new project location: C:\mgtraining\project\2101A\2101A.prj. Click on the Open button. # Look at the Title bar for DC. The new project, 2101A, is shown as the active project. Notice that you did not have to close the old project first, because there can only be one project active at a time. Therefore as soon as you make the new project active, the previous active project is automatically closed. # Just as a check, use the Project >> Settings command to make sure the project settings were correctly copied from the seed project. You should have C:\mgtraining\common\libraries\master\master.lmc listed as the central library, and all of the other settings you made previously in this diaglogue should still be in effect. # The changes you made in the Project >> PCB Integration menu should also be the same as what you set up in the seed project. If not, call your instructor. You now have the project file that will be used for the rest of this class Part 4 Schematic and Compile This part will introduce you to the process of creating a new file, opening multiple pages of a file, placing Devices and Symbols, and saving your work. Follow the step-by-step directions below. The example pages follow the lab instructions. # Use the Project >> Open command to activate the 2101A project. file>>open, in c:\mgtraining \project\example\ ,open the schematic files ExpPCB1.sbk, Array.sbk, in c:\mgtraining \project\opamp\, open the file opamp.sbk, and save all these files in c:\mgtraining \project\2101A\, and include all these file in the project. # Select the File >> New command. Make sure the file type on the diaglogue is set to schematic and click the OK button. # Use the File >> Save As command to name this file D_2_A.sbk. Answer Yes to the prompt to add this file to the project. # Select the Place >> Device command and choose DCP in the diaglogue. In parts Database tab, in Partition, choose 5474, then in Parts found, select 74ALS00_SOP, then press place, put the device in the schematic as the figure. # Edit>> Array Copy, input 4 in number of rows, 1 in number of columns. Then place the 4 devices in the figure. # Do as in step 4 choose 74ALS1008_SOP,74ALS187_DIP and 74ALS49_SOP, and set them in the right position as those in figure. # place>>block, a diaglogue named place block pop up, choose opamp, and then place 2 blocks at the right of the figure, and # place>>bus, and draw the two buses DA_Bus(16:23) and BANK(0:1),RAMWR(0:1),WR(0:1),give the name by double click the bus, and input the name in net name Note: BANK(0:1),RAMWR(0:1),WR(0:1), is one bus not three. # place>>wire, draw all the wires as tho se in the fig,. # place>>symble, find basic>CON_HIER_I;1, then place 3 devices on the left of the figure. # place>>symble, find basic>CON_HIER_O;1, then place 2 devices on the right of the figure, give them names as those in the fig, RAMRD should give names as RAMRD~, then, connect the connectors with the buses or wires. # . Execute the Tools >> Verify… command. In the Select by Group area of the File Verify diaglogue, make sure that only the All errors, All warnings and Schematic checkboxes are checked on. In the Options area of the diaglogue, change the Scope to Design, and click on the Repair errors button. . Click the OK button to start the Verify tool. Once all errors have been corrected and all warnings have been understood and, if necessary, corrected, you are finished with this part of the Lab. Continue with the CDB section. The CDB The purpose of this section of the Lab exercise is to create the Common Database version of your schematic design, in order to prepare the design to be shared with downstream tools. This Lab must be completed before you will be able to do the next section of the Lab. 1. Before you compile the Common Database for any project, you should examine the FileView Tab of the Workspace to be sure that only the schematic files that are intended to be part of the project are listed. If you see extraneous files, remove them by right- clicking on the file name and choosing Remove File from Project from the resulting popup menu. This will prevent the compiler from including any schematics that are not intended to be a part of the design (for example, “junk” or experimental files). # Choose the Tools >> Other Utilities… menu. . From the list of Design Capture Utilities, choose the Compile CDB utility and click the Apply button (or double-click on the Compile CDB utility). . Make sure the project file listed is correct. It should show C:\mgtraining\project\2101a\2101a.prj in the project file field. # Observe the Command Output window. If it says there were no errors or warnings, go on to the next step. If there were errors or warnings, you must fix them. The log file you created, cdblog.txt, contains the same messages as the Command Output window, so that you can refer to these messages if necessary by opening the log file in the Notepad Editor. If you need help understanding the error messages, call your instructor. Once you have successfully compiled the CDB, dismiss the Command Output window, Cancel the CDB Compiler utility, and Cancel the Design Capture Utilities. You now have a commo n database for your project. The Packager This section of the Lab exercise is to create the Packaging information and update the design, in order to prepare the design to be shared with downstream tools. This Lab must be completed before you will be able to do the next Lab. # Check the Project >> Settings Design Tab to ensure that the “Absorb instance data …” option is set. . Make sure all of your schematic files are closed. # Choose the Tools >> Other Utilities… menu. # From the list of Design Capture Utilities, choose the Packager utility and click the Apply button (or double-click on the Packager utility). # Make sure the project file listed is correct. It should show C:\mgtraining\project\2101a\2101a.prj in the project file field. # Leave the Packager Options set to default values (if you wish, you can check No Compile, since we just successfully compiled the CDB a few steps ago – it is up to you). # Click the Apply button. # Observe the output window. If it says there were no errors or warnings, go on to step . If there were errors or warnings, you must fix them. Read the .\integration\partpkg.log file which is automatically created. It contains information about any errors or warnings the packager generated. # Issue the Tools >> Other Utilities menu. Choose the CDB to BOM utility. Use all of the default settings and create a Bill of Materials for your 21101A project. Note: if you leave the field for configuration file blank, the system will use the default config file pointed to by your project file. The default BOM output file will be called 2101A.BOM and will be located in your project folder. Open the file and examine the results. # Close all of the schematic files in your project. In the Other Utilities diaglogue, run the Cross Reference Utility on your design with all default settings, except make sure to click on the checkbox labeled Annotate the entire design. # Issue the Tools >> Other Utilities command, and open the Connections tool. Choose your favorite netlist style and click the Create button. Once the Netlister has finished, open the netlist file (it will be located in a subfolder that was automatically created under your project folder, called .\vbconn\output) and examine the contents. When finished, close the file. [[Category:Mikroelektronikk]] ac873d5a3f13b6d7c732e670e2aebdf7b024cbca 1179 1178 2010-02-25T10:02:29Z Nfyku 4 wikitext text/x-wiki The purpose of this lab is to practice the operation of PCB design capture and draw a basic schematic. ==Introduction== There are certain important files that you will be familiar with before the end of this course: * filename.prj - the project file, which contains “pointers” to the locations of other files or folders that have * projectrelated information, such as symbol libraries or configuration files. * filename.sbk - the schematic block file, which contains graphical schematic data. * foldername.cdb - the Common Data Base folder (CDB). The CDB is the compiled version of the schematic, and is the interim data base between DC and downstream tools such as Expedition PCB. * Filename.lmc – the LibraryManager Catalogue file. This is the file that holds information about which symbol, cell, and PDB partitions reside in the Central Library. * filename.slb - the symbol partition files where schematic symbols representing logic functions are stored within the Central Library. * filename.pdb – the Part Database partition files where device information is stored within the Central Library. * filename.cel – the Cell partition files where “footprint” information is stored within the Central Library. There are several processes and tools that you will become familiar with: * Design Capture - the processes used during schematic design creation. * The Verify tool – used to check your design for incorrect information or design mistakes. * Compile CDB - the process that compiles the design into the Common Data Base. * Packager - the process that will check the CDB to make sure it has all the relevant data, and then, if required, assign “packaging information,” such as Reference designators and pin numbers, in order to prepare the design for Expedition PCB. * CDB to BOM – the Bill Of Materials Generator utility. Used to build the bill of materials after the packager has completed. * Cross Reference – the utility that assigns page connector annotation information to off-page connector symbols in the schematic file. * Connections – used to generate netlists. ==Part 1 PREPARATION== The purpose of this lab exercise is to familiarize yourself with the location of the data that you will be using for this class, and to set up some configuration files for use later in the class. Down the lab material from the website. Unzip the lab2.zip file to c:\mgtraining, # Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & # Browse to C:\Mgtraining. There are two folders, one named common and the other named project. # Open the project folder. There is a completed project called example. Open it and look at the contents. # Go back up to the Mgtraining folder and then down into the common folder and examine the contents. Note: Normally, the objects that we have included here in the common folder would be on a server on your network. You may have a similar setup or may have a slightly different approach. # Open the Libraries folder, and then the Master folder. This is the Central Library we will be using for the rest of the class. Notice the three files –Master.lmc,SysIndex.cbf, and CentLib.prp. These are files that are important to the way the Library Manager works.Look at the contents of the SymbolLibs, PartsDBLibs ,and CellDBLibs folders. The files in each of the folders are library object partitions. # Browse to the software load directory on this machine: C:\mentor\2000.5 \VBDC\config\vbdc # Copy cdb2bom.asc and crossref.asc from here into the C:\Mgtraining\common\config folder. We will examine the contents of these files and edit them later in the class. # Return to the C:\Mgtraining\common folder. Make anew folder under the common folder. Name the new folder Seed_Projects. You are going to create a seed project in this location later in this class. ==Part 2.Creat a seed project== The purpose of this lab exercise is to guide you through the process of creating projects. At the end of this lab, you will have created two new projects. The first is a “seed” project. It will be created by using the Project >> New command, and then the appropriate project settings will be made. The second project will be created from the seed project, using the Project >> Copy command. The second project will be used for the rest of the exercises in this class. Create the Seed Project: Note: In “real life” the seed projects may already be created for you – in this class we will create a new seed project in order to illustrate the process. # Launch DC using Start >> Programs >> Mentor Graphics WG2000.5 >> Design Capture >> Design Capture. # Select the Project >> New command. # In the Project Location field of the New Project Wizard, browse to the folder C:\mgtraining\common\seed_projects using the browse button to the right of the field. click the OK button once you have selected the Seed folder. # In the Project Name field, type in the project name seed1, then click on the Next button on the diaglogue. # We will not add any design files to this seed project, so click on the Next button at the bottom of the diaglogue. # Examine the Project Summary, and then click on the Finish button. # Notice that the seed project you have just created is automatically the active project in DC (see the name of the project in the Titlebar at the top of the Design Capture window). # Select the Project >> Settings pulldown menu. # On the Central Library Tab, select the Browse button beside the Central Library field. Browse to the library: C:\mgtraining\common\libraries\master \master.lmc # Select the File Locations tab on the diaglogue. Change the Configuration file type to Project Options. Click in the field that shows the path to the current config file and click on the Browse button. Browse to: C:\mgtraining\common\config\vbdcsys_C_seed .asc This config file was placed here for you by the system administrator for this class. Editing the project file to point to this config file, as you have just done, will cause the system to use this customized configuration file for any subsequent project that uses this seed project as a template. # click the Edit File button on the diaglogue. Look down through the config file to get an idea of what kinds of settings can be made in this file, but don’t change anything. When you are finished, close the config file. # Click the OK button on the diaglogue. # Select the Project >> PCB Integration pulldown menu. Uncheck the checkbox labeled Forward annotation. This will prevent anyone from reading this design into Expedition PCB before we are ready to release the project to board layout. # Next, check the checkbox labeled Packaging so that no one can accidentally run the packager in Repackage All mode (unless and until you uncheck this box). # Make sure the checkbox labeled Back annotation is checked (on), and the option to Generate FLATNETNAME properties is based on Schematic Net Name changes. # Click the OK button on the diaglogue. You now have a seed project that can be used as a “template” for starting any other job that will require the same project settings. Remember that at most work environments, the seed project will be located at a shared point on the network so that everyone can access it. ==Part 3 Create a project from the seed project== Create the class project: # Select the Project >> Copy command. # In the Old Project field, make sure the current project is listed as: C:\mgtraining\common\seed_projects\seed1 \seed1.prj # In the Project Name field, type in a project name of 2101A (you do not have to type in the .prj extension - in fact, it won’t let you). # In the Project Location field, type in the following pathname: C:\mgtraining\project\2101A. Click on the OK button on the diaglogue. # At this point, the new project has been created, but it is not the active project. Select the Project >> Open command, and browse to the new project location: C:\mgtraining\project\2101A\2101A.prj. Click on the Open button. # Look at the Title bar for DC. The new project, 2101A, is shown as the active project. Notice that you did not have to close the old project first, because there can only be one project active at a time. Therefore as soon as you make the new project active, the previous active project is automatically closed. # Just as a check, use the Project >> Settings command to make sure the project settings were correctly copied from the seed project. You should have C:\mgtraining\common\libraries\master\master.lmc listed as the central library, and all of the other settings you made previously in this diaglogue should still be in effect. # The changes you made in the Project >> PCB Integration menu should also be the same as what you set up in the seed project. If not, call your instructor. You now have the project file that will be used for the rest of this class Part 4 Schematic and Compile This part will introduce you to the process of creating a new file, opening multiple pages of a file, placing Devices and Symbols, and saving your work. Follow the step-by-step directions below. The example pages follow the lab instructions. # Use the Project >> Open command to activate the 2101A project. file>>open, in c:\mgtraining \project\example\ ,open the schematic files ExpPCB1.sbk, Array.sbk, in c:\mgtraining \project\opamp\, open the file opamp.sbk, and save all these files in c:\mgtraining \project\2101A\, and include all these file in the project. # Select the File >> New command. Make sure the file type on the diaglogue is set to schematic and click the OK button. # Use the File >> Save As command to name this file D_2_A.sbk. Answer Yes to the prompt to add this file to the project. # Select the Place >> Device command and choose DCP in the diaglogue. In parts Database tab, in Partition, choose 5474, then in Parts found, select 74ALS00_SOP, then press place, put the device in the schematic as the figure. # Edit>> Array Copy, input 4 in number of rows, 1 in number of columns. Then place the 4 devices in the figure. # Do as in step 4 choose 74ALS1008_SOP,74ALS187_DIP and 74ALS49_SOP, and set them in the right position as those in figure. # place>>block, a diaglogue named place block pop up, choose opamp, and then place 2 blocks at the right of the figure, and # place>>bus, and draw the two buses DA_Bus(16:23) and BANK(0:1),RAMWR(0:1),WR(0:1),give the name by double click the bus, and input the name in net name Note: BANK(0:1),RAMWR(0:1),WR(0:1), is one bus not three. # place>>wire, draw all the wires as tho se in the fig,. # place>>symble, find basic>CON_HIER_I;1, then place 3 devices on the left of the figure. # place>>symble, find basic>CON_HIER_O;1, then place 2 devices on the right of the figure, give them names as those in the fig, RAMRD should give names as RAMRD~, then, connect the connectors with the buses or wires. # . Execute the Tools >> Verify… command. In the Select by Group area of the File Verify diaglogue, make sure that only the All errors, All warnings and Schematic checkboxes are checked on. In the Options area of the diaglogue, change the Scope to Design, and click on the Repair errors button. . Click the OK button to start the Verify tool. Once all errors have been corrected and all warnings have been understood and, if necessary, corrected, you are finished with this part of the Lab. Continue with the CDB section. The CDB The purpose of this section of the Lab exercise is to create the Common Database version of your schematic design, in order to prepare the design to be shared with downstream tools. This Lab must be completed before you will be able to do the next section of the Lab. 1. Before you compile the Common Database for any project, you should examine the FileView Tab of the Workspace to be sure that only the schematic files that are intended to be part of the project are listed. If you see extraneous files, remove them by right- clicking on the file name and choosing Remove File from Project from the resulting popup menu. This will prevent the compiler from including any schematics that are not intended to be a part of the design (for example, “junk” or experimental files). # Choose the Tools >> Other Utilities… menu. . From the list of Design Capture Utilities, choose the Compile CDB utility and click the Apply button (or double-click on the Compile CDB utility). . Make sure the project file listed is correct. It should show C:\mgtraining\project\2101a\2101a.prj in the project file field. # Observe the Command Output window. If it says there were no errors or warnings, go on to the next step. If there were errors or warnings, you must fix them. The log file you created, cdblog.txt, contains the same messages as the Command Output window, so that you can refer to these messages if necessary by opening the log file in the Notepad Editor. If you need help understanding the error messages, call your instructor. Once you have successfully compiled the CDB, dismiss the Command Output window, Cancel the CDB Compiler utility, and Cancel the Design Capture Utilities. You now have a commo n database for your project. The Packager This section of the Lab exercise is to create the Packaging information and update the design, in order to prepare the design to be shared with downstream tools. This Lab must be completed before you will be able to do the next Lab. # Check the Project >> Settings Design Tab to ensure that the “Absorb instance data …” option is set. . Make sure all of your schematic files are closed. # Choose the Tools >> Other Utilities… menu. # From the list of Design Capture Utilities, choose the Packager utility and click the Apply button (or double-click on the Packager utility). # Make sure the project file listed is correct. It should show C:\mgtraining\project\2101a\2101a.prj in the project file field. # Leave the Packager Options set to default values (if you wish, you can check No Compile, since we just successfully compiled the CDB a few steps ago – it is up to you). # Click the Apply button. # Observe the output window. If it says there were no errors or warnings, go on to step . If there were errors or warnings, you must fix them. Read the .\integration\partpkg.log file which is automatically created. It contains information about any errors or warnings the packager generated. # Issue the Tools >> Other Utilities menu. Choose the CDB to BOM utility. Use all of the default settings and create a Bill of Materials for your 21101A project. Note: if you leave the field for configuration file blank, the system will use the default config file pointed to by your project file. The default BOM output file will be called 2101A.BOM and will be located in your project folder. Open the file and examine the results. # Close all of the schematic files in your project. In the Other Utilities diaglogue, run the Cross Reference Utility on your design with all default settings, except make sure to click on the checkbox labeled Annotate the entire design. # Issue the Tools >> Other Utilities command, and open the Connections tool. Choose your favorite netlist style and click the Create button. Once the Netlister has finished, open the netlist file (it will be located in a subfolder that was automatically created under your project folder, called .\vbconn\output) and examine the contents. When finished, close the file. [[Category:Mikroelektronikk]] d1deb4a5a8c1c79d196a5fbaf60de837860e099c 0 3 1181 1072 2010-02-25T10:48:29Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the University of Bergen. For questions and enquiries Contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] av Department of Physics and Technology. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 3b59fd7f5881814fdbd8727ac893f4b594020412 1182 1181 2010-02-25T10:50:32Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at Department of Physics and Technology at the University of Bergen. For questions and enquiries Contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] be4c0e54eed96dbd0f55f02492103bcbc33eb0da 1184 1182 2010-02-26T09:56:33Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 82c206dc2db92a19ab329993e12489f78561e3b5 1195 1184 2010-03-10T10:32:53Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 7cd01e4833728cbdb734e2a56d05a4b59f4a1654 0 278 1185 1108 2010-03-01T09:36:39Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] dd045c8a802c354df9000239ada943f18561adac 0 25 1186 1111 2010-03-10T08:13:59Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [XJTAG] Boundary Scan with XJTAG * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare [[Category:Mikroelektronikk]] b943aaf215d65b580b19f0c55bead5a4bcc06770 1187 1186 2010-03-10T08:14:23Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare [[Category:Mikroelektronikk]] 1fa920ccfec6a7f33e5ac5cb81fab9d22396fc38 0 189 1188 570 2010-03-10T08:37:03Z Nfyku 4 wikitext text/x-wiki XJEase and XJDeveloper Tutorial You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. XJDemo version 1.2 XJDemo version 2.0 W If you have an earlier XJDemo board (most likely version 1.2), then please use the tutorial file on your installation CD in the "XJDemo 1.2" directory or contact XJTAG Support (support@xjtag.com). Overview This tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The structure of the tutorial is as follows: Circuit description The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. Creating the project file You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. Running the connection test We run a connection test and demonstrate various types of error detection using the XJDemo board. Simple device testing We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. More complex device testing We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. Design reuse Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. DFT Analysis The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. -------------------------------------------------------------------------------- Next © 2009 XJTAG Ltd. All rights reserved. XJTAG Version 2.3.6 fa5189923b79e641160e58c38bb4f0ac1ad37fe9 1189 1188 2010-03-10T08:50:24Z Nfyku 4 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[File:XJDemo v1.2.png]][[File:XJDemo v2.0.png]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the # , then please use the tutorial file on your installation CD in the "XJDemo 1.2" directory or contact XJTAG Support (support@xjtag.com). ==Overview== This tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. 33908bb0f6b69038a7490daaf67a0306a2529393 1192 1189 2010-03-10T08:58:39Z Nfyku 4 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from .... ==Overview== This tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. c265d70fa0819b8563d911f849b87558ff7bdfcc 1193 1192 2010-03-10T09:00:13Z Nfyku 4 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from .... The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. 7142190c8e8318841d629e2a488750921c8350c5 1194 1193 2010-03-10T09:14:22Z Nfyku 4 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [[file:XJTAG Demo Board.zip|here]] (you have to log in first). The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. [[Category:Mikroelektronikk]] 5aae2d0791714ce2e106b05b9ffe17a09737badc 1198 1194 2010-03-10T12:57:42Z Nfyku 4 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [[http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip|here]]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. [[Category:Mikroelektronikk]] c3681ddd0b734cc243fd5a8629d60923e2c6683f 1199 1198 2010-03-10T12:58:03Z Nfyku 4 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [[http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. [[Category:Mikroelektronikk]] ba1bf99fbab2424c9a0af9e2a4cd9df8d11a79fc 1200 1199 2010-03-10T12:58:33Z Nfyku 4 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. [[Category:Mikroelektronikk]] 2c5c32971e57b709f690dc297d7cfd860f483588 1207 1200 2010-03-15T11:01:42Z Ave082 33 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board. Refer to the schematic for the pinmapping for page 11 of the tutorial. # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. [[Category:Mikroelektronikk]] b23ec3a666c6e0764cd25718198a3b183341a7ba 6 291 1190 2010-03-10T08:51:12Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 292 1191 2010-03-10T08:51:36Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 4 1196 126 2010-03-10T10:39:33Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] <br><br> == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://www.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://www.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://www.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://www.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://www.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://www.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://www.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://www.ift.uib.no/firmware/alme/loop.o loop.o] | [http://www.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://www.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://www.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://www.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://www.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://www.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://www.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://www.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://www.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://www.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://www.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://www.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://www.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://www.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://www.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://www.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br><br> === Download Section === [http://www.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://www.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://www.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://www.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://www.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://www.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://www.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://www.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://www.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://www.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://www.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://www.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://www.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://www.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://www.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://www.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://www.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://www.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://www.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://www.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://www.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://www.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://www.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://www.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://www.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://www.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://www.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] <br><br> [[Category:Alice]] 9962cd789889cfb07e9b3770610f40c5f4af783c 1197 1196 2010-03-10T10:42:06Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] <br><br> == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] <br><br> [[Category:Alice]] f64836becdb95a2a215b220c932e85d1b95be85a 0 31 1201 1086 2010-03-12T15:35:47Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: '' DRC (Design rule check) '' LVS (Layout versus schematic test) '' Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC studio er startet, se [https://wikihost.uib.no/ift/index.php/IC_studio IC studio]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de ''design rules'' som gjelder for prosessen. DRC sjekker ''ikke'' om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg ''ICrules'' --> ''Check''. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg ''Options...'' og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg ''OK'' begge steder for å kjøre DRC. Bruk så knappene ''First'' og ''Next'' for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under ''Options...'' trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg ''File'' --> ''Logic'' --> ''Close''. # Fra paletten: Velg ''ICtrace(M)'' # Fra menylinjen velg ''HIT-KIT Utilities > Setup LVS (ICtrace)'' # Klikk på ''Mask Mode'' # Fra paletten: Klikk på ''Load Rules'' # Velg SDL og klikk ''OK'' # Fra paletten: Klikk på ''LVS'' # Trykk på knappen ''Setup LVS...'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da av "Setup LVS (ICtrace)". Kontroller disse. #:[[Image:Setup LVS.png]] # Trykk på knappen ''Setup Trace Props'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Kontroller. #:[[Image:Setup Trace Properties.png]] #likk ''OK'' begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg ''Logic'' --> ''Open'', og angi stien til viewpointet (samme som ''Source Name'' i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasitanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: <br/> Fra paletten: Velg ''ICextract (M)'' <br/> Lukk eventuelle åpne ''logic''. <br/> Klikk ''Lumped'' og fyll ut dialogboksen tilsvarende figuren under. [[Image:extract_mask_lumped_parameters.png]] Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> Skjemaet vil nå se ut omtrent som figuren under. [[Image:sch_parasitics_included.png]] Legg til transistormodellene som skal brukes i simuleringen. <br/> Klikk ''Lib/Temp/Inc'' og legg til følgende sti (for S35): <pre> $AMS_DIR/eldo/s35/cmos53tm.mod </pre> Fra paletten, velg ''Annotations --> Merge all'' <br/> Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 2038707bcd49e9320dfe23e671d088f2b4ac5982 1204 1201 2010-03-12T15:44:54Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: '' DRC (Design rule check) '' LVS (Layout versus schematic test) '' Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icpl/_bk_icpl.html Vi antar nå at IC studio er startet, se [https://wikihost.uib.no/ift/index.php/IC_studio IC studio]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de ''design rules'' som gjelder for prosessen. DRC sjekker ''ikke'' om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. Fra paletten: Velg ''ICrules'' --> ''Check''. [[Image:drc_chedr.png]] Feilmeldingen "Number must be a positive number or zero" kommer av at default-verdien til "Maximum results per rule check" er satt altfor høy eller en negativ verdi. Velg ''Options...'' og sett innstillingene omtrent som på figuren under. Du vil gjerne sette navnet på rapportfilen til noe mer passende... [[Image:drc_options_2.png]] Velg ''OK'' begge steder for å kjøre DRC. Bruk så knappene ''First'' og ''Next'' for å se på feil for feil. Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. De innstillingene vi gjorde under ''Options...'' trenger vi bare gjøre første gang vi kjører DRC etter å ha startet IC Station. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg ''File'' --> ''Logic'' --> ''Close''. # Fra paletten: Velg ''ICtrace(M)'' # Fra menylinjen velg ''HIT-KIT Utilities > Setup LVS (ICtrace)'' # Klikk på ''Mask Mode'' # Fra paletten: Klikk på ''Load Rules'' # Velg SDL og klikk ''OK'' # Fra paletten: Klikk på ''LVS'' # Trykk på knappen ''Setup LVS...'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da av "Setup LVS (ICtrace)". Kontroller disse. #:[[Image:Setup LVS.png|538px]] # Trykk på knappen ''Setup Trace Props'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Kontroller. #:[[Image:Setup Trace Properties.png|417px]] #likk ''OK'' begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg ''Logic'' --> ''Open'', og angi stien til viewpointet (samme som ''Source Name'' i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasistanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: #Fra paletten: Velg ''ICextract (M)'' <br/> #Lukk eventuelle åpne ''logic''. <br/> #Klikk ''Lumped'' og fyll ut dialogboksen tilsvarende figuren under. #:[[Image:extract_mask_lumped_parameters.png|440px]] #Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> #:Skjemaet vil nå se ut omtrent som figuren under.[[Image:sch_parasitics_included.png]] #Legg til transistormodellene som skal brukes i simuleringen. <br/> #Klikk ''Lib/Temp/Inc'' og legg til følgende sti (for S35): #:<pre>$AMS_DIR/eldo/s35/cmos53tm.mod</pre> #Fra paletten, velg ''Annotations --> Merge all'' <br/> #:Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. #Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems "beskriver her", file:///prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html en metode for å lage en selvstendig netlist for krets med parasitiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (Session->Environment->Run Sim) og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene Extract->Mask-Lumped eller Extract->Mask->Distributed istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i Setup->Session->Environment. 0d0f65e9808f0d36fee7cb608f550031d7b3c6af 1205 1204 2010-03-12T16:00:27Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: * DRC (Design rule check) * LVS (Layout versus schematic test) * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 ''/prog/mentor/2006.2b_rhelx86linux/icflow_home/shared/htmldocs/_bk_icpl/_bk_icpl.html''. Vi antar nå at IC studio er startet, se [[IC studio]]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de ''design rules'' som gjelder for prosessen. DRC sjekker ''ikke'' om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. #Fra paletten: Velg ''ICrules'', deretter ''Check''. #Velg Options i pop-up vinduet. #Set ''Maximum results per rule check'' til et passende tall, og velg andre instillinger, f.eks. slik som vist under. #:[[Image:drc_options_2.png]] #Klikk ''OK'' #Klikk ''OK'' i pop-up vinduet for å kjøre DRC. #Bruk så knappene ''First'' og ''Next'' for å se på feil for feil. #:Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg ''File'' --> ''Logic'' --> ''Close''. # Fra paletten: Velg ''ICtrace(M)'' # Fra menylinjen velg ''HIT-KIT Utilities > Setup LVS (ICtrace)'' # Klikk på ''Mask Mode'' # Fra paletten: Klikk på ''Load Rules'' # Velg SDL og klikk ''OK'' # Fra paletten: Klikk på ''LVS'' # Trykk på knappen ''Setup LVS...'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da av "Setup LVS (ICtrace)". Kontroller disse. #:[[Image:Setup LVS.png|538px]] # Trykk på knappen ''Setup Trace Props'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Kontroller. #:[[Image:Setup Trace Properties.png|417px]] #likk ''OK'' begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg ''Logic'' --> ''Open'', og angi stien til viewpointet (samme som ''Source Name'' i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasistanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: #Fra paletten: Velg ''ICextract (M)'' <br/> #Lukk eventuelle åpne ''logic''. <br/> #Klikk ''Lumped'' og fyll ut dialogboksen tilsvarende figuren under. #:[[Image:extract_mask_lumped_parameters.png|440px]] #Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> #:Skjemaet vil nå se ut omtrent som figuren under.[[Image:sch_parasitics_included.png]] #Legg til transistormodellene som skal brukes i simuleringen. <br/> #Klikk ''Lib/Temp/Inc'' og legg til følgende sti (for S35): #:<pre>$AMS_DIR/eldo/s35/cmos53tm.mod</pre> #Fra paletten, velg ''Annotations --> Merge all'' <br/> #:Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. #Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems beskriver i filen ''/prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html'' en metode for å lage en selvstendig nettliste for krets med parasittiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (''Session->Environment->Run Sim'') og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene ''Extract->Mask-Lumped eller Extract->Mask->Distributed'' istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i ''Setup->Session->Environment''. 27d19b0b164161d7e41604d15fc2251346455640 1206 1205 2010-03-12T16:01:19Z Nfyku 4 wikitext text/x-wiki ===IC Station=== Dette dokumentet beskriver: * DRC (Design rule check) * LVS (Layout versus schematic test) * Ekstrahering av parameter fra utlegg Online dokumentasjon kan leses fra firefox på mikroserver2 ''/prog/mentor/2006.2b_rhelx86linux/icflow_home/shared/htmldocs/_bk_icpl/_bk_icpl.html''. Vi antar nå at IC studio er startet, se [[IC studio]]. I tillegg er skjemaet ferdig laget og det er laget et Viewpoint. ==Create cell== Når vi skal lage et utlegg i IC station begynner vi med å lage et nytt "View". Klikk på det biblioteket ditt og høyre-klikk deretter i Cell-vinduet og velg "New View". Velg "View Type" layout og trykk deretter Next og velg "Block" under Layout Definition og vpt_c35b4 under Connectivity Source. Deretter trykker du Finish. Du skal nå få opp IC station. ==DRC (Design Rule Check)== DRC sjekker at utlegget er korrekt i henhold til de ''design rules'' som gjelder for prosessen. DRC sjekker ''ikke'' om transistorer er riktig koblet sammen. Det gjøres i LVS-testen som beskrives senere. #Fra paletten: Velg ''ICrules'', deretter ''Check''. #Velg Options i pop-up vinduet. #Set ''Maximum results per rule check'' til et passende tall, og velg andre instillinger, f.eks. slik som vist under. #:[[Image:drc_options_2.png]] #Klikk ''OK'' #Klikk ''OK'' i pop-up vinduet for å kjøre DRC. #Bruk så knappene ''First'' og ''Next'' for å se på feil for feil. #:Feilene markeres med en hvit ramme i utlegget samtidig som det står en forklarende melding nederst på skjermen. DRC kan også startes fra menyen øverst i vinduet. Se bilde. [[Image:drc_fra_meny.png]] ==LVS (Layout Versus Schematic test)== Når utlegget har passert DRC må vi kjøre LVS-sjekk. Her sjekkes at utlegget stemmer overens med skjemaet. LVS kontrollerer at skjema og utlegg er samme elektriske krets. Dersom noen komponenter er koblet feil sammen eller har feil størrelse i henhold til skjema, får vi melding om det. OBS! Hvis du har åpnet et "logic" i forbindelse med SDL, må dette lukkes nå. Velg ''File'' --> ''Logic'' --> ''Close''. # Fra paletten: Velg ''ICtrace(M)'' # Fra menylinjen velg ''HIT-KIT Utilities > Setup LVS (ICtrace)'' # Klikk på ''Mask Mode'' # Fra paletten: Klikk på ''Load Rules'' # Velg SDL og klikk ''OK'' # Fra paletten: Klikk på ''LVS'' # Trykk på knappen ''Setup LVS...'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Disse innstillingene ble satt da av "Setup LVS (ICtrace)". Kontroller disse. #:[[Image:Setup LVS.png|538px]] # Trykk på knappen ''Setup Trace Props'' #:Dialogboksen du nå får se vil ha innstillinger tilsvarende figuren under. Kontroller. #:[[Image:Setup Trace Properties.png|417px]] #likk ''OK'' begge steder for å kjøre LVS. Sjekk rapportfilen. Hvis LVS-testen gikk bra vil du se et smilefjes i rapporten. Når LVS-testen er vellykket kan vi åpne et vindu i IC Station som viser skjemaet. Velg ''Logic'' --> ''Open'', og angi stien til viewpointet (samme som ''Source Name'' i dialogboksen LVS (Mask)). Ved å klikke på et nett eller en transistor, vil tilsvarende markeres i utlegget. ==IC-extract (Ekstrahering av parasitter)== Når vi simulerer skjemaet vårt i DA simulerer vi bare skjema. Dvs. transistormodeller med ideelle ledninger mellom. Simulatoren vil ikke ta hensyn til parasittiske kapasistanser og resistanser i utlegget. Slike parasitter er avhengig av hvordan transistorene er tegnet, hvor tett vi plasserer dem, hvordan vi foretar ruting osv. For å finne ut hvordan kretsen på utlegget egentlig virker må vi ekstrahere disse parasittene, importere dem i skjemaet vårt og kjøre simulering en gang til. Parasitter representerer ekstra poler, som kan føre til at systemet ikke lengre tilfredsstiller spesifikasjonene. Derfor er det viktig å simulere skjemaet med effektene fra utlegget. Lag en kopi av det originale skjemaet du tegnet i DA (Save sheet as...). Lukk det "gamle" og åpne det nye. Lag et viewpoint av det nye skjemaet. Vi skal bruke det nye skjemaet til simulering med informasjon fra utlegget. <br/> Er du i simuleringsmodus? Gå ut av simuleringsmodus. I IC Sation: #Fra paletten: Velg ''ICextract (M)'' <br/> #Lukk eventuelle åpne ''logic''. <br/> #Klikk ''Lumped'' og fyll ut dialogboksen tilsvarende figuren under. #:[[Image:extract_mask_lumped_parameters.png|440px]] #Åpne skjemaet i DA igjen og gå i simuleringsmodus. <br/> #:Skjemaet vil nå se ut omtrent som figuren under.[[Image:sch_parasitics_included.png]] #Legg til transistormodellene som skal brukes i simuleringen. <br/> #Klikk ''Lib/Temp/Inc'' og legg til følgende sti (for S35): #:<pre>$AMS_DIR/eldo/s35/cmos53tm.mod</pre> #Fra paletten, velg ''Annotations --> Merge all'' <br/> #:Informasjonen fra utlegget er nå inkludert, og fargen har skiftet fra rød til gul. #Sett opp simulering (analyser, plot) og kjør. ==Simulering med parasitteffekter som egen nettliste== AustriMicroSystems beskriver i filen ''/prog/design_kits/ams_hk_3.70/www/hitkit/hk370/icstation/icextract.html'' en metode for å lage en selvstendig nettliste for krets med parasittiske effekter ekstrahert fra layout. Denne simuleres så i DA-IC ved å slå av generering av netlist (''Session->Environment->Run Sim'') og så kjøre simulering hver gang man har ekstrahert på ny. Et viktig tips er å kjøre ekstrahering fra pull-down menyene ''Extract->Mask-Lumped eller Extract->Mask->Distributed'' istedenfor å velge tilsvarende fra paletten. Dermed får man satt de riktige default verdier, og scriptet rewrite_netlist kalles automatisk for nødvendig konvertering av bl.a. modellnavn og måleenheter. Nettlisten som kommer ut inneholder kretsen i en subscircuit. Ved å kommentere vekk linjene med .subckt og .ends kan nettlisten kopieres over nettlisten generert av DA-IC og simuleres med samme plot og målinger. Alternativt kan man i DA-IC velge den ekstraherte nettlisten i ''Setup->Session->Environment''. [[Category:Mikroelektronikk]] 22eb91c3b3f998e8a4446baba158bab6e60f9a64 6 293 1202 2010-03-12T15:36:25Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 294 1203 2010-03-12T15:36:50Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 203 1208 726 2010-03-22T15:06:44Z Dfe002 7 /* Documents to bring */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this) *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. == ALICE shiftwork == * Have a look into the [http://www-linux.gsi.de/~garabat/meu/ShiftGuide.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 5 September 2009 (UTC) 29c09db2211e6acc762c8a677c28e2cae22f45af 1209 1208 2010-03-22T15:40:44Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. Outside of the airport, take Bus 28, Direction: Meyrin-Village. Change to bus 56 Bus, Direction: CERN after a few bus stops. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this) *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 5 September 2009 (UTC) 78def1f16531c5dcfa9d40d0153a45eec8f98000 0 203 1210 1209 2010-03-22T15:53:09Z Dfe002 7 /* How to get to CERN */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this) *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 5 September 2009 (UTC) 062737a2d62968576536b5472286ac98213cfe69 1211 1210 2010-03-22T15:55:15Z Dfe002 7 /* What to do first at CERN */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 12:44, 5 September 2009 (UTC) 4062f7a80916f7532b3668a3a791758f64d09ac9 1212 1211 2010-03-22T15:56:02Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 15:56, 22 March 2010 (UTC) a24870272652bddb9aa069c10056ffe58cc35d22 1235 1212 2010-04-16T14:01:15Z Dfe002 7 /* To do shifts */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: [http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/] == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 15:56, 22 March 2010 (UTC) 321ceb5b01704bbb71305364378f88081ac38167 1236 1235 2010-04-16T14:02:33Z Dfe002 7 /* Documents to bring */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 * In addition it seems that you now need a filled ALICE registration form as well: ** [http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html] == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: [http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/] == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 15:56, 22 March 2010 (UTC) 52748e12e2c78a7b3209be806a7de36dea3264e3 1237 1236 2010-04-16T14:03:09Z Dfe002 7 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 15:56, 22 March 2010 (UTC) 3b65e7df19351dcd61db18da18d18f81422b63ad 1238 1237 2010-04-16T14:35:04Z Dfe002 7 /* To do shifts */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 15:56, 22 March 2010 (UTC) 41a1b8332f0c34d457b5b460950314a92e6457c9 0 38 1213 76 2010-03-23T10:52:06Z Lce042 43 wikitext text/x-wiki =Building and simulating a simple CMOS inverter in Cadence Virtuoso= ==Starting up== To invoke Cadence Virtuoso, type the following from unix shell ssh -X mikroserver2 source /prog/design_kits/cadence_init/cshrc.cadence.ams ams_cds -tech c35b4 -nologo -mode fb Virtuoso Mixed Signal Design Environment should now start up: <img src="uploads/icms_uppstart.JPG" /> In the "icms" dialog box, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach an existing techfile". Then click the OK button. When asked for technology, choose TECH_C35B4. <img src="uploads/new_library.JPG" /> After successfully creating the new library, it is time to create your first design. In the "icms" dialog box, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name (for example "torcell", as I did). You must also specify which library the design belongs to, and here you specify the library that you have just created (in my case, TORLIB). <img src="uploads/create_new_file.JPG" /> Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: <img src="uploads/virtuoso_schematic_editor.JPG" /> ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos" (for n-type transistor) or "pmos" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. <img src="uploads/library_browser.JPG" /> 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. For the transistors, set the "Width" and "Lenght" properties to "4u" and "1u". For the pmos transistor, set the "Model name" property to "modp". For the nmos transistor, set the "Model name" property to "modn". As we will see later, the "modn" and "modp" models correspond to SPICE simulation models used by the simulator in the Analog Environment. <img src="uploads/edit_object_properties.JPG" /> <img src="uploads/edit_object_prop_pmos.JPG" /> 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Tools > Analog Environment". The "Virtuoso Analog Environment" should now come up: <img src="uploads/analog_env_1.JPG" /> ==Simulating the design== 8. Choose "Setup > Simulator/Directory/Host" and set spectreS as your simulator. 9. Choose "Setup > Model Path" and add directory "/prog/hk_37/spectreS/c35/cmos53/tm" to your model path. 10. Choose "Simulation > Netlist > Create Raw". 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. <img src="uploads/choosing_analyses.JPG" /> <img src="uploads/select_comp_parameter.JPG" /> The analog environment should now look like this: <img src="uploads/analog_env_2.JPG" /> 13. Choose "Simulation > Run". 14. After the simulation has completed, choose "Results > Plot Outputs > DC". The outputs should look like this: <img src="uploads/plot_output_dc.JPG" /> To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. <img src="uploads/add_pin.JPG" /> After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". <img src="uploads/create_cellview_from_cellview.JPG" /> Now press OK: <img src="uploads/symbol_generation_options.JPG" /> Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: <img src="uploads/symbol_editor.JPG" /> Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] aadb19af8854970c5f9014ef4a465802fc3b24e8 1221 1213 2010-03-25T13:18:50Z Lce042 43 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== To invoke Cadence Virtuoso, type the following from unix shell ssh -X mikroserver2 source /prog/design_kits/cadence_init/cshrc.cadence.ams ams_cds -tech c35b4 -nologo -mode fb Virtuoso Mixed Signal Design Environment should now start up: <img src="uploads/icms_uppstart.JPG" /> In the "icms" dialog box, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach an existing techfile". Then click the OK button. When asked for technology, choose TECH_C35B4. <img src="uploads/new_library.JPG" /> After successfully creating the new library, it is time to create your first design. In the "icms" dialog box, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name (for example "torcell", as I did). You must also specify which library the design belongs to, and here you specify the library that you have just created (in my case, TORLIB). <img src="uploads/create_new_file.JPG" /> Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: <img src="uploads/virtuoso_schematic_editor.JPG" /> ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos" (for n-type transistor) or "pmos" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. <img src="uploads/library_browser.JPG" /> 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. For the transistors, set the "Width" and "Lenght" properties to "4u" and "1u". For the pmos transistor, set the "Model name" property to "modp". For the nmos transistor, set the "Model name" property to "modn". As we will see later, the "modn" and "modp" models correspond to SPICE simulation models used by the simulator in the Analog Environment. <img src="uploads/edit_object_properties.JPG" /> <img src="uploads/edit_object_prop_pmos.JPG" /> 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Tools > Analog Environment". The "Virtuoso Analog Environment" should now come up: <img src="uploads/analog_env_1.JPG" /> ==Simulating the design== 8. Choose "Setup > Simulator/Directory/Host" and set spectreS as your simulator. 9. Choose "Setup > Model Path" and add directory "/prog/hk_37/spectreS/c35/cmos53/tm" to your model path. 10. Choose "Simulation > Netlist > Create Raw". 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. <img src="uploads/choosing_analyses.JPG" /> <img src="uploads/select_comp_parameter.JPG" /> The analog environment should now look like this: <img src="uploads/analog_env_2.JPG" /> 13. Choose "Simulation > Run". 14. After the simulation has completed, choose "Results > Plot Outputs > DC". The outputs should look like this: <img src="uploads/plot_output_dc.JPG" /> To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. <img src="uploads/add_pin.JPG" /> After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". <img src="uploads/create_cellview_from_cellview.JPG" /> Now press OK: <img src="uploads/symbol_generation_options.JPG" /> Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: <img src="uploads/symbol_editor.JPG" /> Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 5a30b8336fa6afaa5803391c61d9f8b5af6654b4 1222 1221 2010-03-25T13:25:56Z Lce042 43 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 source /prog/design_kits/cadence_init/cshrc.cadence.ams ams_cds -tech c35b4 -nologo -mode fb Virtuoso Mixed Signal Design Environment should now start up: <img src="uploads/icms_uppstart.JPG" /> In the "icms" dialog box, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach an existing techfile". Then click the OK button. When asked for technology, choose TECH_C35B4. <img src="uploads/new_library.JPG" /> After successfully creating the new library, it is time to create your first design. In the "icms" dialog box, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name (for example "torcell", as I did). You must also specify which library the design belongs to, and here you specify the library that you have just created (in my case, TORLIB). <img src="uploads/create_new_file.JPG" /> Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: <img src="uploads/virtuoso_schematic_editor.JPG" /> ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos" (for n-type transistor) or "pmos" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. <img src="uploads/library_browser.JPG" /> 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. For the transistors, set the "Width" and "Lenght" properties to "4u" and "1u". For the pmos transistor, set the "Model name" property to "modp". For the nmos transistor, set the "Model name" property to "modn". As we will see later, the "modn" and "modp" models correspond to SPICE simulation models used by the simulator in the Analog Environment. <img src="uploads/edit_object_properties.JPG" /> <img src="uploads/edit_object_prop_pmos.JPG" /> 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Tools > Analog Environment". The "Virtuoso Analog Environment" should now come up: <img src="uploads/analog_env_1.JPG" /> ==Simulating the design== 8. Choose "Setup > Simulator/Directory/Host" and set spectreS as your simulator. 9. Choose "Setup > Model Path" and add directory "/prog/hk_37/spectreS/c35/cmos53/tm" to your model path. 10. Choose "Simulation > Netlist > Create Raw". 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. <img src="uploads/choosing_analyses.JPG" /> <img src="uploads/select_comp_parameter.JPG" /> The analog environment should now look like this: <img src="uploads/analog_env_2.JPG" /> 13. Choose "Simulation > Run". 14. After the simulation has completed, choose "Results > Plot Outputs > DC". The outputs should look like this: <img src="uploads/plot_output_dc.JPG" /> To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. <img src="uploads/add_pin.JPG" /> After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". <img src="uploads/create_cellview_from_cellview.JPG" /> Now press OK: <img src="uploads/symbol_generation_options.JPG" /> Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: <img src="uploads/symbol_editor.JPG" /> Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 92d3bf982626e6910dc1b177debdf94039de2c11 0 4 1214 1197 2010-03-24T08:37:39Z Stud4729 6 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] <br><br> == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - seqeunce_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i><br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] <br><br> [[Category:Alice]] 86aaa032e86500090378cf3d8425c635cc574647 1215 1214 2010-03-24T08:45:01Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] <br><br> == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.<br><br> <p>Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.<br><br> <ul> <li>Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.</li> <li>Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.</li> <li>Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. </li> </ul> <br> === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> <ol>Updating the DCS boards: <li> Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> <li> Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> </ol> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... <br> === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i><br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] 9156fb39dad5b5148503ed2dee0232d1e86266be 1216 1215 2010-03-24T08:51:11Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to <b>4.1</b>. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i><br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] ecec5401c33fa4e5fd5018b51b44059834da56c0 1217 1216 2010-03-24T08:55:10Z Nfyku 4 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/messagebuffer/ CVS database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i><br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/trigger_receiver/ CVS database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/phos_bc/ CVS database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/vhdlcvs/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] fb9ea0e9c5137a0028004cd15e047818e48cb42a 1230 1217 2010-04-07T09:26:09Z Nfyku 4 Changed from CVS to SVN wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i><br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 0238a3f6aced61a5fd14d4402f537d0961a3976a 0 25 1218 1187 2010-03-25T12:42:50Z Dfe002 7 /* Mikroelektronikk */ wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av matrin 09.6 XL BGA lodding maskin [[Category:Mikroelektronikk]] 186cf0eff71cae8ad09afe6247368bfdcc37afaf 1219 1218 2010-03-25T12:43:19Z Dfe002 7 /* Mikroelektronikk */ wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) [[Category:Mikroelektronikk]] cd97244bcab965d278c006f59d5bffe1d7fd300e 0 295 1220 2010-03-25T13:17:30Z Dfe002 7 Created page with '= Reworking = = Martin 09.6 XL machine = ==Hardware== === Gas & power === === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==...' wikitext text/x-wiki = Reworking = = Martin 09.6 XL machine = ==Hardware== === Gas & power === === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==== == Software - Easy older == === Desolder === ==== Rapid profiling ==== ==== Classic profiling ==== ==== Optimize profile ==== === Auto Vision Placer === === Despense === === Solder === === Clean Pad === c68c65b0bf34f70b98a1664a2a985b0e24cd9e06 1223 1220 2010-03-25T13:30:52Z Dfe002 7 wikitext text/x-wiki = Reworking = = Martin 09.6 XL machine = ==Hardware== === Gas & power === === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==== ==== Lenses ==== == Software - Easy older == === Desolder === ==== Rapid profiling ==== ==== Classic profiling ==== ==== Optimize profile ==== === Despense === === Auto Vision Placer === === Solder === === Clean Pad === 0c3285d04be233a53fa633caed8f928090d8cf32 1224 1223 2010-03-25T13:34:07Z Dfe002 7 wikitext text/x-wiki = Reworking = = Martin 09.6 XL machine = == Hardware == === Gas & power === === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==== ==== Lenses ==== === Handling tools === == Software - Easy older == === Desolder === ==== Rapid profiling ==== ==== Classic profiling ==== ==== Optimize profile ==== === Despense === === Auto Vision Placer === === Solder === === Clean Pad === == ReBalling == [[User:Dfe002|Dominik]] 13:34, 25 March 2010 (UTC) 8ec324e8352a183b7c3d7008d1c9c14d96e95254 1227 1224 2010-03-25T13:39:37Z Dfe002 7 Protected "[[BGA lodding]]": only for intern use ([edit=sysop] (indefinite) [move=sysop] (indefinite)) [cascading] wikitext text/x-wiki = Reworking = = Martin 09.6 XL machine = == Hardware == === Gas & power === === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==== ==== Lenses ==== === Handling tools === == Software - Easy older == === Desolder === ==== Rapid profiling ==== ==== Classic profiling ==== ==== Optimize profile ==== === Despense === === Auto Vision Placer === === Solder === === Clean Pad === == ReBalling == [[User:Dfe002|Dominik]] 13:34, 25 March 2010 (UTC) 8ec324e8352a183b7c3d7008d1c9c14d96e95254 1228 1227 2010-03-26T09:03:09Z Dfe002 7 wikitext text/x-wiki = Reworking = = Martin 09.6 XL machine = == Hardware == === Gas & power === * Open the valves on the Nitrogen bottle, the nitrogen line close the bottle (red lever), and the nitrogen line close to the soldering machine (red lever). * Open the valve for the pressurized air behind the white wall cabinet (red lever). * Switch on the soldering machine: One switch located on the bottom unit of the soldering machine, on the behind side in the middle. One switch on the DBL (the control unit, on the behind side, a bit to the right. === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==== ==== Lenses ==== === Handling tools === == Software - Easy older == === Desolder === he default profile is chosen with the hot air nozzle that you select. But for the desoldering, to create a profile, I would have a bit longer time for preheating and soldering, because you don't want to end up with a half desoldered BGA ;) The profiling will shorten the time, and we can't use the desoldered FPGA anyway, since we can't reball it. There are different profilers to create a BGA profile (rapid, classic, ...). I don't recall wich one it is, but there is one where it asks you to attach temperature probes to the top side of the BGA, and to the underside (as good as you can get it between the solderballs). You can use the teflon tape to attach the probes, but you should avoid air bubbles close to the probes under the tape. With one of the profilers you can then desolder the BGA, the profile goes through pre heating and soldering state, and there is a button "solder point" which is greyed out in the beginning. During the solder phase this button becomes clickable, and you should use the dentist tools to carefully try to lift the BGA from the board. When the solder is liquid and you can lift the BGA, then you should click "solder point" and take off the BGA. Then comes a cool down phase. Then you should have a customised profile for this BGA and board. ==== Rapid profiling ==== ==== Classic profiling ==== ==== Optimize profile ==== === Despense === If you are done with test runs of placing, and plan to solder, you can use the "Dispense" to apply flux to the board with the foot pedal and the with brush. === Auto Vision Placer === Before you need to choose the placement nozzle that will hold your BGA with a vacuum. It should be square about 1x1 cm for you BGA. Loosing the silver screw on the arm over the placement nozzle and disconnect the rubber tube. Start AVP and choose the lens that your BGA fits in. I think the one that fits for you is called 'Maxi BGA'. Then you mark the outline on the PCB, we got the best results with taking the inside edges of the solder placement marks, but in theory you can also take the lands itself. You need to mark two adjacent corners and the opposing edge. Since there is no mark for the edge, you can take the line from the solder placement marks as far to the inside as you can get. When you are happy with the drawn square, you can turn on the vacuum put the BGA on the tip of the placement nozzle. Then you click "nozzle down" and mark the outline of the BGA, again two corners and one edge. Because of the fuzzy corners where the BGAs where cut/broken off, you might have set the cursor that the corner fits to the clean cut edges. THen you can place the BGA, and check if it aligns correctly. === Solder === After the placing from above, you can select the solder part. Before starting the soldering, you should check that the hot air nozzle aligns properly with the BGA, and you might have to move the arm a bit manually to get it aligned (there is a switch to turn the magnet of on the base of the arm). Then you have to check the height, that the solder nozzle doesn't touch the PCB or the BGA. In order to not bend the placement arm, put your thumb under the placement arm, and push down the red part with your pointer. You can adjust the height with the screw on the top. There shouldn't be more then 1mm between the solder nozzle and the board. Then you can click "Solder" and it will ask you if the underheater support and nozzle is in place. This is the last chance to fix it. When you click next, the machine goes through the solder profile. After soldering you can save the report as pdf somewhere (print to pdf printer). === Clean Pad === With the clean pad function the underheater is on, and you can use the hot air pen from the stand next to the PC to clean the solder rests of the PCB, also using the suction pen from the stand. The lands can come off easily if you are not careful. But if you use a new board to solder, you don't need to do this. == ReBalling == The process of attaching new solderballs to a previously desoldered BGA is called reballing. For this we need a small reballing oven, into which the BGA goes, and a mask that corresponds to the ball layout on the BGA. [[User:Dfe002|Dominik]] 09:03, 26 March 2010 (UTC) 21c47884c44b7df6ec41d59304909d676aae7d3f 1229 1228 2010-03-26T09:03:39Z Dfe002 7 /* Gas & power */ wikitext text/x-wiki = Reworking = = Martin 09.6 XL machine = == Hardware == === Gas & power === * Open the valves on the Nitrogen bottle, the nitrogen line close to the bottle (red lever), and the nitrogen line close to the soldering machine (red lever). * Open the valve for the pressurized air behind the white wall cabinet (red lever). * Switch on the soldering machine: One switch located on the bottom unit of the soldering machine, on the behind side in the middle. One switch on the DBL (the control unit, on the behind side, a bit to the right. === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==== ==== Lenses ==== === Handling tools === == Software - Easy older == === Desolder === he default profile is chosen with the hot air nozzle that you select. But for the desoldering, to create a profile, I would have a bit longer time for preheating and soldering, because you don't want to end up with a half desoldered BGA ;) The profiling will shorten the time, and we can't use the desoldered FPGA anyway, since we can't reball it. There are different profilers to create a BGA profile (rapid, classic, ...). I don't recall wich one it is, but there is one where it asks you to attach temperature probes to the top side of the BGA, and to the underside (as good as you can get it between the solderballs). You can use the teflon tape to attach the probes, but you should avoid air bubbles close to the probes under the tape. With one of the profilers you can then desolder the BGA, the profile goes through pre heating and soldering state, and there is a button "solder point" which is greyed out in the beginning. During the solder phase this button becomes clickable, and you should use the dentist tools to carefully try to lift the BGA from the board. When the solder is liquid and you can lift the BGA, then you should click "solder point" and take off the BGA. Then comes a cool down phase. Then you should have a customised profile for this BGA and board. ==== Rapid profiling ==== ==== Classic profiling ==== ==== Optimize profile ==== === Despense === If you are done with test runs of placing, and plan to solder, you can use the "Dispense" to apply flux to the board with the foot pedal and the with brush. === Auto Vision Placer === Before you need to choose the placement nozzle that will hold your BGA with a vacuum. It should be square about 1x1 cm for you BGA. Loosing the silver screw on the arm over the placement nozzle and disconnect the rubber tube. Start AVP and choose the lens that your BGA fits in. I think the one that fits for you is called 'Maxi BGA'. Then you mark the outline on the PCB, we got the best results with taking the inside edges of the solder placement marks, but in theory you can also take the lands itself. You need to mark two adjacent corners and the opposing edge. Since there is no mark for the edge, you can take the line from the solder placement marks as far to the inside as you can get. When you are happy with the drawn square, you can turn on the vacuum put the BGA on the tip of the placement nozzle. Then you click "nozzle down" and mark the outline of the BGA, again two corners and one edge. Because of the fuzzy corners where the BGAs where cut/broken off, you might have set the cursor that the corner fits to the clean cut edges. THen you can place the BGA, and check if it aligns correctly. === Solder === After the placing from above, you can select the solder part. Before starting the soldering, you should check that the hot air nozzle aligns properly with the BGA, and you might have to move the arm a bit manually to get it aligned (there is a switch to turn the magnet of on the base of the arm). Then you have to check the height, that the solder nozzle doesn't touch the PCB or the BGA. In order to not bend the placement arm, put your thumb under the placement arm, and push down the red part with your pointer. You can adjust the height with the screw on the top. There shouldn't be more then 1mm between the solder nozzle and the board. Then you can click "Solder" and it will ask you if the underheater support and nozzle is in place. This is the last chance to fix it. When you click next, the machine goes through the solder profile. After soldering you can save the report as pdf somewhere (print to pdf printer). === Clean Pad === With the clean pad function the underheater is on, and you can use the hot air pen from the stand next to the PC to clean the solder rests of the PCB, also using the suction pen from the stand. The lands can come off easily if you are not careful. But if you use a new board to solder, you don't need to do this. == ReBalling == The process of attaching new solderballs to a previously desoldered BGA is called reballing. For this we need a small reballing oven, into which the BGA goes, and a mask that corresponds to the ball layout on the BGA. [[User:Dfe002|Dominik]] 09:03, 26 March 2010 (UTC) 7911491f1fa15d1c0b6914d8389a8ee1e2a096f8 0 21 1225 1035 2010-03-25T13:35:58Z Dfe002 7 /* Meetings and conferences */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany === For internal use === [[material]] that can be used in official presentations. ce7b83b864e41b272f9a0755e9ad0701726ea454 1231 1225 2010-04-15T05:59:28Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 10.05. - 14.05.10: The XIV International Conference on Calorimetry in High Energy Physics - Calor2010, Beijing, China, http://bes3.ihep.ac.cn/conference/calor2010/ * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany == For internal use == [[material]] that can be used in official presentations. d9f363626b389f8a9f1d33367cb2dc5953cec5bd 1232 1231 2010-04-15T06:00:57Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian, Per-Ivar * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 10.05. - 14.05.10: The XIV International Conference on Calorimetry in High Energy Physics - Calor2010, Beijing, China, http://bes3.ihep.ac.cn/conference/calor2010/ * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany == For internal use == [[material]] that can be used in official presentations. 80bea138fe961766858b97a5e8a5134294e2f3fa 0 196 1226 863 2010-03-25T13:37:00Z Dfe002 7 /* XYZ-table setup */ wikitext text/x-wiki Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find money for it. ==XYZ-table setup== * <s>1µm fiber to scan the detectors.</s> * <s>optical gating grid to calibrate the XYZ-table.</s> * <s>New camera for the X/Y table</s> [[User:Dfe002|Dominik]] 13:37, 25 March 2010 (UTC) 8fad1d50f4d49915efd5781c4215cc91fd3be90a 0 57 1233 134 2010-04-15T14:12:41Z Nfyku 4 Changed from www to web.ift.uib.no, plus some minor formatting changes wikitext text/x-wiki [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] __TOC__ == General DCS board related questions == === What species of Linux is running on the DCS board? === The Linux on the DCS board is a compilation of several projects suited for embedded systems * Kernel: [http://www.arm.linux.org.uk/ The ARM Linux Project] with minor changes. Kernel version 2.4.21 * regular programs: [http://www.busybox.net/about.html BusyBox], The Swiss Army Knife of Embedded Linux * C library: [http://uclibc.org/about.html uClibc] === I cant find common UNIX tools like diff on the DCS board === The version of busybox included into the linux during the early days of the DCS board doesn't support commands like od, cmp and diff. An additional package contains those three programs. To install them * download the package [http://web.ift.uib.no/~kjeks/download/dcsboard-addon-0.1.tar.gz dcsboard-addon] * unzip it to the root (/) directory (the archive contains all necessary sub folders) * e.g. on the DCS board do wget -P /tmp/ http://web.ift.uib.no/~kjeks/download/dcsboard-addon-0.1.tar.gz tar xzvf /tmp/dcsboard-addon-0.1.tar.gz -C / === Can I compile programs on the DCS board? === No, the Linux on the DCS board is a light-weight operating system which just provides the environment to run programs. Of course, this could be a compiler, but this doesn't make sense. One uses a cross compiler on another system to build the executables. === What is a cross compiler? === Cross compiling means to compile and build on a build system which is different from the system the program has to run on. Each cpu architecture has its own instruction set, binary format aso. The compiler translates the program source code into machine code for a certain architecture. Most embedded systems (like the one on the DCS board) don't provide fully functional operating systems. The use of a cross compiler is a convenient tool to create executables on another workstation. The Arm Linux on the DCS board uses gcc 3.3.1 configured for arm-uclibc. === How do I install a cross compiler and use it? === The Arm Linux on the DCS board is compiled with gcc 3.3.1 and uses uclibc as standard library. This page gives just a short recipe for the installation. For further details look at the [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html DCS board Arm Linux] page. To install the compiler you have two possibilities: * The precompiled package<br>There is a precompiled package configured for <i>uclibc</i> and <i>/usr/local/arm/3.3.1</i>. The compiler has to be exactly at that place. *# Download the [http://web.ift.uib.no/~kjeks/download/arm-uclibc-3.3.1-toolchain.tar.bz2 package]. *# Create a folder /usr/local/arm on your build machine or ask your system administrator to do it for you and give you write access. *# Unpack the package tar xvjkf arm-uclibc-3.3.1-toolchain.tar.bz2 -C /usr/local/arm * Install the gcc from scratch and configure it for arm linux. There is a helper script on the [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html DCS board Arm Linux] page. In both cases you must add the compilers's binary directory to your search path. For the first it is <i>/usr/local/arm/3.3.1/bin</i>, e.g. # c-shell setenv PATH ${PATH}:/usr/local/arm/3.3.1/bin # or # bash export PATH=${PATH}:/usr/local/arm/3.3.1/bin === How can I copy the executable to the DCS board? === scp <filename> root@<address of the board>:/tmp This will place the file in the /tmp directory of the board. The better solution is to mount a network directory. Note that the /tmp directory on the board is erased each time it boots since it is not located in the flash ram. === Where are all the files from the /tmp directory after reboot === You should not place any files you want to keep in the /tmp folder since this is areased after reboot. === How do I mount a network directory on the DCS board? === This is two-fold. An extern machine has to provide the directory and the DCS board has to mount it. # The server, can be any Linux machine the board has access to<br>Usually you need root access to configure the server. #* nfs deamon has to run on the host machine #** start nfs service: <b>/sbin/service nfs start</b> #** stop nfs service: <b>/sbin/service nfs stop</b> #** status information: <b>/sbin/service nfs status</b> #* configure the allowed export directories in <b>/etc/exports</b>, e.g. with a line like<br><b>/nfs_export/dcscard dcs0034(rw)</b><br>the directory '/nfs_export/dcscard' can be mounted by the machine 'dcs0034' in read-write mode #* finally after altering <b>/etc/exports</b> you might have to run <b>exportfs -a</b> in order to update the list of NFS exported file systems # The client, i.e. the DCS board #* create a directory <b>/mnt</b> if it does not exist #* use the command <b>/usr/local/sbin/nfsmount</b> to mount the network directory, e.g.<br><b>/usr/local/sbin/nfsmount <host>:/nfs_export/dcscard /mnt rw</b> #* Of course you can name the mountpoint on the DCS board whatever you want === I can not write to my network directory=== check if * the server allows write access (/etc/exportfs) * the DCS board mounts the network disc in read-write mode * the permissions for the directory on the server allow write access, keep in mind that the applications on the DCS board are running under a different user than usually you are on the host machine, and thus 'others' have to have write access === How can I connect to the DCS board from a Windows computer by using the serial line? === First of all you need to have the proper serial line connector cable [http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/mechanic/RS232cable01.gif Schematics]. In one side of the connector there is a small red dot. This should be connected to the connector on the short egde next to the ttc-fiber connector. Connect it to a free com-port on your pc. In windows use 'hyperterminal' with the following settings: Baud Rate: 57600 Data Bits: 8 Parity: None Stop Bits: 1 Flow Control: None == InterComLayer related questions == === What is the InterComLayer? === === Where do I have to install/run the InterComLayer? === === What tools can I use to monitor the DIM framework? === == FeeServer related questions == === What is a FeeServer? === === What is the ControlEngine? === == rcu shell related questions == The sections will be filled as the questions come in [[Category:DCS]] d263020752a0d6ebe90cc7e56f261f5ae1bc22b2 1234 1233 2010-04-15T14:16:31Z Nfyku 4 wikitext text/x-wiki [[Detector Control System (DCS) for ALICE Front-end electronics | Detector Control System]] __TOC__ == General DCS board related questions == === What species of Linux is running on the DCS board? === The Linux on the DCS board is a compilation of several projects suited for embedded systems * Kernel: [http://www.arm.linux.org.uk/ The ARM Linux Project] with minor changes. Kernel version 2.4.21 * regular programs: [http://www.busybox.net/about.html BusyBox], The Swiss Army Knife of Embedded Linux * C library: [http://uclibc.org/about.html uClibc] === I cant find common UNIX tools like diff on the DCS board === The version of busybox included into the linux during the early days of the DCS board doesn't support commands like od, cmp and diff. An additional package contains those three programs. To install them * download the package [http://web.ift.uib.no/~kjeks/download/dcsboard-addon-0.1.tar.gz dcsboard-addon] * unzip it to the root (/) directory (the archive contains all necessary sub folders) * e.g. on the DCS board do wget -P /tmp/ http://web.ift.uib.no/~kjeks/download/dcsboard-addon-0.1.tar.gz tar xzvf /tmp/dcsboard-addon-0.1.tar.gz -C / === Can I compile programs on the DCS board? === No, the Linux on the DCS board is a light-weight operating system which just provides the environment to run programs. Of course, this could be a compiler, but this doesn't make sense. One uses a cross compiler on another system to build the executables. === What is a cross compiler? === Cross compiling means to compile and build on a build system which is different from the system the program has to run on. Each cpu architecture has its own instruction set, binary format aso. The compiler translates the program source code into machine code for a certain architecture. Most embedded systems (like the one on the DCS board) don't provide fully functional operating systems. The use of a cross compiler is a convenient tool to create executables on another workstation. The Arm Linux on the DCS board uses gcc 3.3.1 configured for arm-uclibc. === How do I install a cross compiler and use it? === The Arm Linux on the DCS board is compiled with gcc 3.3.1 and uses uclibc as standard library. This page gives just a short recipe for the installation. For further details look at the [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html DCS board Arm Linux] page. To install the compiler you have two possibilities: * The precompiled package<br>There is a precompiled package configured for <i>uclibc</i> and <i>/usr/local/arm/3.3.1</i>. The compiler has to be exactly at that place. # Download the [http://web.ift.uib.no/~kjeks/download/arm-uclibc-3.3.1-toolchain.tar.bz2 package]. # Create a folder /usr/local/arm on your build machine or ask your system administrator to do it for you and give you write access. # Unpack the package #: <pre>tar xvjkf arm-uclibc-3.3.1-toolchain.tar.bz2 -C /usr/local/arm</pre> # Install the gcc from scratch and configure it for arm linux. There is a helper script on the [http://frodo.nt.fh-koeln.de/%7Etkrawuts/dcs.html DCS board Arm Linux] page. In both cases you must add the compilers's binary directory to your search path. For the first it is <i>/usr/local/arm/3.3.1/bin</i>, e.g. # c-shell setenv PATH ${PATH}:/usr/local/arm/3.3.1/bin # or # bash export PATH=${PATH}:/usr/local/arm/3.3.1/bin === How can I copy the executable to the DCS board? === scp <filename> root@<address of the board>:/tmp This will place the file in the /tmp directory of the board. The better solution is to mount a network directory. Note that the /tmp directory on the board is erased each time it boots since it is not located in the flash ram. === Where are all the files from the /tmp directory after reboot === You should not place any files you want to keep in the /tmp folder since this is areased after reboot. === How do I mount a network directory on the DCS board? === This is two-fold. An extern machine has to provide the directory and the DCS board has to mount it. # The server, can be any Linux machine the board has access to<br>Usually you need root access to configure the server. #* nfs deamon has to run on the host machine #** start nfs service: <b>/sbin/service nfs start</b> #** stop nfs service: <b>/sbin/service nfs stop</b> #** status information: <b>/sbin/service nfs status</b> #* configure the allowed export directories in <b>/etc/exports</b>, e.g. with a line like<br><b>/nfs_export/dcscard dcs0034(rw)</b><br>the directory '/nfs_export/dcscard' can be mounted by the machine 'dcs0034' in read-write mode #* finally after altering <b>/etc/exports</b> you might have to run <b>exportfs -a</b> in order to update the list of NFS exported file systems # The client, i.e. the DCS board #* create a directory <b>/mnt</b> if it does not exist #* use the command <b>/usr/local/sbin/nfsmount</b> to mount the network directory, e.g.<br><b>/usr/local/sbin/nfsmount <host>:/nfs_export/dcscard /mnt rw</b> #* Of course you can name the mountpoint on the DCS board whatever you want === I can not write to my network directory=== check if * the server allows write access (/etc/exportfs) * the DCS board mounts the network disc in read-write mode * the permissions for the directory on the server allow write access, keep in mind that the applications on the DCS board are running under a different user than usually you are on the host machine, and thus 'others' have to have write access === How can I connect to the DCS board from a Windows computer by using the serial line? === First of all you need to have the proper serial line connector cable [http://www.kip.uni-heidelberg.de/ti/DCS-Board/current/mechanic/RS232cable01.gif Schematics]. In one side of the connector there is a small red dot. This should be connected to the connector on the short egde next to the ttc-fiber connector. Connect it to a free com-port on your pc. In windows use 'hyperterminal' with the following settings: Baud Rate: 57600 Data Bits: 8 Parity: None Stop Bits: 1 Flow Control: None == InterComLayer related questions == === What is the InterComLayer? === === Where do I have to install/run the InterComLayer? === === What tools can I use to monitor the DIM framework? === == FeeServer related questions == === What is a FeeServer? === === What is the ControlEngine? === == rcu shell related questions == The sections will be filled as the questions come in [[Category:DCS]] 98f3243bb2d218150d9cd7a4760cf8596e536e23 0 137 1239 1140 2010-04-29T16:03:17Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] . We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. To get write access to these pages you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] === Job openings in our group=== There is a postdoc position in our group open, watch these pages from a link to the application. More info below. There will be more positions (PhD) in the near future. * [[Post doc, spring 2010, see the link| http://web.ift.uib.no/~lipniack/jobs/bergen_16.02.10.pdf]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 781e6e9aed9bd2462c73b1be51fec0f2dd2acf4a 1240 1239 2010-04-29T16:04:54Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[Spaatind2010|Nordic High Energy Physics Conference, Spaatind 2010]] === Job openings in our group=== There is a postdoc position in our group open, watch these pages from a link to the application. More info below. There will be more positions (PhD) in the near future. * [[Post doc, spring 2010, see the link| http://web.ift.uib.no/~lipniack/jobs/bergen_16.02.10.pdf]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] ee551282acf35178d8ee2fc1b42055a8d098f699 0 234 1241 1027 2010-06-01T10:18:40Z Aaa014 28 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] === Ongoing Master theses === * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] [[Orjan Dale - Master Thesis]] b12c7f135fb8fa28d31d841ffe94413041c7d65b 6 296 1242 2010-06-01T11:20:32Z Aaa014 28 Neutrinos escaping detection is one of the main problems in mass reconstruction with tau leptons. They must be neglected or corrected for in some way. This thesis discusses two methods of handling the neutrinos in different ways. The Collinear Approximation (CA) builds upon the assumption that the neutrinos travel in the same direction as the visible tau decay products. The boost method neglects the neutrino energy contribution in the leading visible tau, as seen from the mother particle's reference system. The methods have been studied with simulated \Z°→τ+τ- , \H°→τ+τ-, and QCD samples, and with early data from ATLAS. This work shows that the weaknesses of CA is that the transverse angle of the transverse missing energy has to lie between the transverse angle of the two visible taus, and that it collapses with back-to-back taus in the transverse plane. A strength of the CA is that it uses the missing energy, which is all information available about the neutrinos. The CA works better for boosted taus, i.e. taus decaying from heavy particles, like H° and Z°. The weaknesses of the boost method are that it does not use the transverse missing energy information, and that the distribution is not easily fitted, but the method is still under development on these points. The strength of the boost method is that it works for all tau pairs, making it a good complimentary method to the CA. Both methods work in \Z°→τ+τ- and \H°→τ+τ- events, and can be potentially applied to other decay chains as well. In the future, many studies will include mass reconstruction from tau leptons, where both the CA and the boost method will be important methods. wikitext text/x-wiki Neutrinos escaping detection is one of the main problems in mass reconstruction with tau leptons. They must be neglected or corrected for in some way. This thesis discusses two methods of handling the neutrinos in different ways. The Collinear Approximation (CA) builds upon the assumption that the neutrinos travel in the same direction as the visible tau decay products. The boost method neglects the neutrino energy contribution in the leading visible tau, as seen from the mother particle's reference system. The methods have been studied with simulated \Z°→τ+τ- , \H°→τ+τ-, and QCD samples, and with early data from ATLAS. This work shows that the weaknesses of CA is that the transverse angle of the transverse missing energy has to lie between the transverse angle of the two visible taus, and that it collapses with back-to-back taus in the transverse plane. A strength of the CA is that it uses the missing energy, which is all information available about the neutrinos. The CA works better for boosted taus, i.e. taus decaying from heavy particles, like H° and Z°. The weaknesses of the boost method are that it does not use the transverse missing energy information, and that the distribution is not easily fitted, but the method is still under development on these points. The strength of the boost method is that it works for all tau pairs, making it a good complimentary method to the CA. Both methods work in \Z°→τ+τ- and \H°→τ+τ- events, and can be potentially applied to other decay chains as well. In the future, many studies will include mass reconstruction from tau leptons, where both the CA and the boost method will be important methods. 59f70b640efd6ce01e4942f028757662c53a875e 6 297 1243 2010-06-01T12:05:39Z Aaa014 28 Hensikten med denne masteroppgaven er aa lage en laboratorieveiledning til en o�velse i et fag for laveregradstudenter ved Universitetet i Bergen. Foruten aa fi�nne en interessant fysisk verdi er hovedhensikten at studentene skal laere behandle resultatene paa en hen- siktsmessig maate. Dette innebaerer blant annet aa behandle usikkerheter, aa �finne en verdi som representerer hele maaleserien og aa kunne vise resultatene paa en god maate. O�velsen gaar ut paa aa maale forholdet mellom elektronets ladning og masse, e/m, med et katodestraalero�r. I forarbeidet blir tre metoder pro�vd ut; avb�oyning av elektroner i et magnetisk felt der en verdi av avb�oyningen bestemmer radiusen, ingen avbo�yning ved kryssede E-og B-felt og avbo�yning i magnetisk felt der flere punkter blir benyttet for aa estimere radiusen. Den sistnevnte metoden gaar ut paa aa estimere sirkelbanen og dens sentrum ved hjelp av min- imalisering av chikvadratet. Denne viste seg aa bryte sammen. Kun resultatene fra den fo�rste metoden inneholdt den kjente verdien av forholdet innenfor usikkerhetsintervallet, men usikkerheten var kun en sto�rrelsesorden lavere enn verdien for forholdet. Maalingene var veldig avhengig av usikkerheten i avlesningen av y-verdiene og denne usikkerheten kunne vaert forminsket ytterligere. Den andre metoden hadde lavere usikkerhet, men inneholdt ikke den kjente verdien i usikkerhetsintervallet. Denne metoden hadde ogsaa noen utfordringer knyttet til innsamlingen av data. Derfor blir kun den f�orste meto- den gjennomgaatt i laboratorieveiledningen. Denne blir utformet med en generell teoridel som skal gj�ore studentene mentalt forberedt paa det de skal laere og den inneholder en utf�orelsesdel som skal fungere som et stillas for studentene. Der staar det hint om hvordan �ovelsen kan gjennomf�ores og sp�orsmaal til diskusjon som skal besvares. wikitext text/x-wiki Hensikten med denne masteroppgaven er aa lage en laboratorieveiledning til en o�velse i et fag for laveregradstudenter ved Universitetet i Bergen. Foruten aa fi�nne en interessant fysisk verdi er hovedhensikten at studentene skal laere behandle resultatene paa en hen- siktsmessig maate. Dette innebaerer blant annet aa behandle usikkerheter, aa �finne en verdi som representerer hele maaleserien og aa kunne vise resultatene paa en god maate. O�velsen gaar ut paa aa maale forholdet mellom elektronets ladning og masse, e/m, med et katodestraalero�r. I forarbeidet blir tre metoder pro�vd ut; avb�oyning av elektroner i et magnetisk felt der en verdi av avb�oyningen bestemmer radiusen, ingen avbo�yning ved kryssede E-og B-felt og avbo�yning i magnetisk felt der flere punkter blir benyttet for aa estimere radiusen. Den sistnevnte metoden gaar ut paa aa estimere sirkelbanen og dens sentrum ved hjelp av min- imalisering av chikvadratet. Denne viste seg aa bryte sammen. Kun resultatene fra den fo�rste metoden inneholdt den kjente verdien av forholdet innenfor usikkerhetsintervallet, men usikkerheten var kun en sto�rrelsesorden lavere enn verdien for forholdet. Maalingene var veldig avhengig av usikkerheten i avlesningen av y-verdiene og denne usikkerheten kunne vaert forminsket ytterligere. Den andre metoden hadde lavere usikkerhet, men inneholdt ikke den kjente verdien i usikkerhetsintervallet. Denne metoden hadde ogsaa noen utfordringer knyttet til innsamlingen av data. Derfor blir kun den f�orste meto- den gjennomgaatt i laboratorieveiledningen. Denne blir utformet med en generell teoridel som skal gj�ore studentene mentalt forberedt paa det de skal laere og den inneholder en utf�orelsesdel som skal fungere som et stillas for studentene. Der staar det hint om hvordan �ovelsen kan gjennomf�ores og sp�orsmaal til diskusjon som skal besvares. 2c8a73e70294635010f1cb4b56e298d48bc7c4ec 1246 1243 2010-06-02T07:15:11Z Nfyku 4 fixed æøå problem related to UTF-8 wikitext text/x-wiki Hensikten med denne masteroppgaven er å lage en laboratorieveiledning til en øvelse i et fag for laveregradstudenter ved Universitetet i Bergen. Foruten å finne en interessant fysisk verdi er hovedhensikten at studentene skal lære behandle resultatene på en hen- siktsmessig måte. Dette innebærer blant annet å behandle usikkerheter, å finne en verdi som representerer hele måleserien og å kunne vise resultatene på en god måte. øvelsen går ut på å måle forholdet mellom elektronets ladning og masse, e/m, med et katodestrålerør. I forarbeidet blir tre metoder prøvd ut; avbøyning av elektroner i et magnetisk felt der en verdi av avbøoyningen bestemmer radiusen, ingen avbøyning ved kryssede E-og B-felt og avbøyning i magnetisk felt der flere punkter blir benyttet for å estimere radiusen. Den sistnevnte metoden går ut på å estimere sirkelbanen og dens sentrum ved hjelp av min- imalisering av chikvadratet. Denne viste seg å bryte sammen. Kun resultatene fra den første metoden inneholdt den kjente verdien av forholdet innenfor usikkerhetsintervallet, men usikkerheten var kun en størrelsesorden lavere enn verdien for forholdet. Målingene var veldig avhengig av usikkerheten i avlesningen av y-verdiene og denne usikkerheten kunne vært forminsket ytterligere. Den andre metoden hadde lavere usikkerhet, men inneholdt ikke den kjente verdien i usikkerhetsintervallet. Denne metoden hadde også noen utfordringer knyttet til innsamlingen av data. Derfor blir kun den første meto- den gjennomgått i laboratorieveiledningen. Denne blir utformet med en generell teoridel som skal gjøre studentene mentalt forberedt på det de skal lære og den inneholder en utførelsesdel som skal fungere som et stillas for studentene. Der står det hint om hvordan øvelsen kan gjennomføres og spørsmål til diskusjon som skal besvares. a1867e42ec1938e2b9fc4023f928367a21bd4428 6 298 1244 2010-06-01T14:04:26Z Aaa014 28 The ATLAS working group has defined some safe variables that is well understood at the ATLAS early data taking. With these safe variables they have developed some safe cuts by using TMVA, that removes approximatly 70%(Loose), 50%(Medium), and 30%(Tight) of the signal. In this thesis I have made a likelihoodfunction based on the safe variables, figure 4.19, if we make cuts on this likelihood we manage to keep the same amount of signal while we reject more background than the safe cuts do. As shown in table 4.2 a cut on this likelihoodfunction will reject 5 times more background than the loose cut, and 2 times more background than the medium cut. This means that it can be a good idea to use those likelihoodcuts instead of using the safe cuts. wikitext text/x-wiki The ATLAS working group has defined some safe variables that is well understood at the ATLAS early data taking. With these safe variables they have developed some safe cuts by using TMVA, that removes approximatly 70%(Loose), 50%(Medium), and 30%(Tight) of the signal. In this thesis I have made a likelihoodfunction based on the safe variables, figure 4.19, if we make cuts on this likelihood we manage to keep the same amount of signal while we reject more background than the safe cuts do. As shown in table 4.2 a cut on this likelihoodfunction will reject 5 times more background than the loose cut, and 2 times more background than the medium cut. This means that it can be a good idea to use those likelihoodcuts instead of using the safe cuts. 67f38a58333d8edfe5d3b51c9f15ca232b0c21fe 6 299 1245 2010-06-02T07:07:13Z Aaa014 28 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 242 1247 1071 2010-06-02T09:07:15Z Nfyku 4 Added the new Trigger Mode register. Updated status register info. wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 48 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} bb460034bc66e195beb1b4e7f90a41e389dd1313 0 3 1248 1195 2010-06-02T09:16:15Z Nfyku 4 Info about the semi-multiple event buffer scheme has been added (new sparse read-out). wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 50===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 58058ca7d0d1b82335680119a9ba72212f4bfb39 1251 1248 2010-06-04T11:02:43Z Nfyku 4 added download for version 50 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 50===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now beefing read-out. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 65e7fbe2556eeee6e411495f3bbb3592c1693964 1252 1251 2010-06-04T11:04:06Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 50===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now beefing read-out. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 917261ee35cda58ead36a264774beb5ac07b7e6e 1253 1252 2010-06-04T11:17:04Z Nfyku 4 Added something about the settings needed for the new sparse mode wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 50===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now beefing read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 5c528c503a79005d86b06bc58c01e432e2ee0606 1254 1253 2010-06-09T07:15:43Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 50===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now beefing read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Download====== The new version will soon be available <!--*[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga2.bit busybox_fpga2.bit]--> ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 2b40dd2e1433d533594ee50e5eb3a004b8d7f9b2 1255 1254 2010-06-09T07:21:22Z Nfyku 4 Reverted edits by [[Special:Contributions/Nfyku|Nfyku]] ([[User talk:Nfyku|Talk]]) to last revision by [[User:St09909|St09909]] wikitext text/x-wiki == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/~st09909/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added and an updated register table exists on the wiki : [[Busy_Box_and_related/BusyBox_Registers|BusyBox Registers]] In short: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBoxUserGuide.pdf] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/~st09909/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] <!--#[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf|Busybox User Guide, Rikard Bølgen]]--> #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/~st09909/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 1fc2d0bc986ceb2694cbc22119ca35af4d19be62 1256 1255 2010-06-11T12:00:52Z Nfyku 4 Updated with revison 52 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 52===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now beefing read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Download====== The new version will soon be available *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision50/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] f056346a6bbd6a495ac1874fec49f7e1f2246725 1257 1256 2010-06-11T12:01:49Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 52===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now beefing read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Download====== The new version will soon be available *[http://web.ift.uib.no/firmware/BusyBox/revision52/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision52/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision52/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 21c90f7ad1631a0010313aaf32e7ed551d5e24bb 1258 1257 2010-06-23T07:51:01Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 53===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now beefing read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== #The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. #bb_bus_read now works correctly in busybox_tb_pkg. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision53/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision53/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] f77a207c2a17e9d9e0aa5ec537e1ea88ed7cae58 1259 1258 2010-06-23T09:20:04Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 53===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: #Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== #The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. #bb_bus_read now works correctly in busybox_tb_pkg. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision53/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision53/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision53/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] bb8dfc10676ea01f7c253db3a25c3934677eb074 2 300 1249 2010-06-04T08:42:46Z Tbu082 19 Created page with 'Jørn Mæland' wikitext text/x-wiki Jørn Mæland 1e97a2f89ad9ea2a12de7ca52dd176d37e04fe83 6 301 1250 2010-06-04T08:49:51Z Jma049 40 Theories that include extra dimension, may change the Planck scale to the order of the electroweak symmetry breaking scale. This may allow for the creation of black hole and string balls at particle physics experiments, like those at the Large Hadron Collider. The decay of black holes and sting balls will have unique signatures, that allows us to discover them. The main focus for this thesis have been to studying the decay of simulated black holes and string balls. Where we have been focusing on methods to remove standard model backgrounds from our signal selection. If black hole and string balls are able to be produced at the Large Hadron Collider, we conclude that ATLAS will have great discovery potential for black holes and string balls. wikitext text/x-wiki Theories that include extra dimension, may change the Planck scale to the order of the electroweak symmetry breaking scale. This may allow for the creation of black hole and string balls at particle physics experiments, like those at the Large Hadron Collider. The decay of black holes and sting balls will have unique signatures, that allows us to discover them. The main focus for this thesis have been to studying the decay of simulated black holes and string balls. Where we have been focusing on methods to remove standard model backgrounds from our signal selection. If black hole and string balls are able to be produced at the Large Hadron Collider, we conclude that ATLAS will have great discovery potential for black holes and string balls. 0ae93c7bb163bf4b64b4ff29062dfe4f5d615e40 0 242 1260 1247 2010-06-29T07:57:02Z Nfyku 4 Updated current version to 53 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 53 |0x0022 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} a5ff826e5b933ef00189af9edee8d47131f86e6f 1262 1260 2010-08-10T11:34:50Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3051 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3053 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3054 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} c42b7e735debe534f08c26a177deae26bcd2f3aa 1265 1262 2010-08-18T13:47:08Z Nfyku 4 Corrected addresses for Event info and Event Error wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3012 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3013 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3050 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3052 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3053 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 482c170bc7e2fe8e00df9137212055c661376825 1266 1265 2010-08-18T13:50:50Z Nfyku 4 Corrected L1_msg_latency register addresses wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L0 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L0 trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L0 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3014 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3015 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3050 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3052 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3053 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} dcbf305da9bf2b02737c99bd50f49cb5c99e0797 0 3 1261 1259 2010-08-10T11:27:34Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 430ddbb6c6656806e3fcbfe05d376f03f5c881f9 1264 1261 2010-08-17T11:06:09Z Nfyku 4 Added revision 55 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======Trigger Receiver event FIFO-bug-fix====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behavior of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxUserGuide.pdf BusyBox User Guide (updated for FW rev 41)] #[[Media:Rikard_Bolgen_-_BusyBox_User_Guide.pdf‎|Master Thesis, Rikard Bølgen]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 675b2b04828bd2d45408303c769efeb6140a38a6 1333 1264 2010-09-14T14:44:03Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======Trigger Receiver event FIFO-bug-fix====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behavior of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] b8dfd6bb3666c540df6f00b3eca3c18211d0f3ec 1334 1333 2010-09-14T14:45:12Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======Trigger Receiver event FIFO-bug-fix====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behavior of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] d9598143f23aafd7ac5415bf1045a519d0bb2583 0 4 1263 1230 2010-08-17T06:36:50Z Stud4729 6 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> '''v 1.5 (17.08.2010)'''<br> <ul> <li>Fix done by Attiq Ur Rehman:<br> There is minor change in the "fifo wrapper":<br> Line #73 new signal cnt_dn<br> Line #91 comparison with "read_counter"<br> Line #170,172,174 check of possible logical conditions<br> This file was used for the RCU firmware (from 10th July and on wards) to fix the Erroneous behavior causing busy condition. </li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.5_source_files.rar Firmware v 1.5 - VHDL files, including testbench]<br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool].<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 890c4858d5e8d9b66cd3d9552ada60b81121f002 0 7 1267 15 2010-08-23T10:56:39Z Dfe002 7 wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way: <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: 1. Load the bit-file for the FPGA 2. Type the name of the device as you can see above in “DeviceName” 3. Load the XML configuration file 4. Type the directory where the frames are saved to 5. Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. d4fbb5d685d66f17e1396ccdc6591b0fb064100f 1268 1267 2010-08-23T10:57:46Z Dfe002 7 wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: # Load the bit-file for the FPGA # Type the name of the device as you can see above in “DeviceName” # Load the XML configuration file # Type the directory where the frames are saved to # Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. bdc91fa48753827a8c416457941a66ada91568e8 1269 1268 2010-08-23T11:16:12Z Dfe002 7 wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: # Load the bit-file for the FPGA # Type the name of the device as you can see above in “DeviceName” # Load the XML configuration file # Type the directory where the frames are saved to # Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. ===Download Section=== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/BitGui.zip BitGui.zip] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Linux.tar.gz generateConfigFiles_Linux.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Windows.rar generateConfigFiles_Windows.rar] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtCore.tar.gz libQtCore.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtGUI.tar.gz libQtGUI.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/psa3.pdf Internship Report] | [[User:Dfe002|Dominik]] 11:16, 23 August 2010 (UTC) d6e6212da5547bf4842bbd8af26f0e68d5f4fa8b 1270 1269 2010-08-23T11:34:59Z Dfe002 7 wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: # Load the bit-file for the FPGA # Type the name of the device as you can see above in “DeviceName” # Load the XML configuration file # Type the directory where the frames are saved to # Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. ===Download Section=== ====Program, libraries and instructions==== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/BitGui.zip BitGui.zip] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Linux.tar.gz generateConfigFiles_Linux.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Windows.rar generateConfigFiles_Windows.rar] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtCore.tar.gz libQtCore.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtGUI.tar.gz libQtGUI.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/psa3.pdf Internship Report] | ====Firmware packages==== =====RCU 260710===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710initconf.hex 260710initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710scrub.hex 260710scrub.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710readback.hex 260710readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710framefiles.tar.gz 260710framefiles.tar.gz]<br> =====LSR_TRG 301109===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109initconf.hex lsr_trg301109initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109scrub.hex lsr_trg301109scrub.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109readback.hex lsr_trg301109readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109framefiles.tar.gz lsr_trg301109framefiles.tar.gz]<br> [[User:Dfe002|Dominik]] 11:34, 23 August 2010 (UTC) e55063fd1b3d899e5a09b1c8a5c903145f608fbe 1271 1270 2010-08-23T11:42:09Z Dfe002 7 wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: # Load the bit-file for the FPGA # Type the name of the device as you can see above in “DeviceName” # Load the XML configuration file # Type the directory where the frames are saved to # Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. ===Download Section=== ====Program, libraries and instructions==== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/BitGui.zip BitGui.zip] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Linux.tar.gz generateConfigFiles_Linux.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Windows.rar generateConfigFiles_Windows.rar] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtCore.tar.gz libQtCore.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtGUI.tar.gz libQtGUI.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/psa3.pdf Internship Report] | ====Firmware packages==== =====RCU 260710===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710initconf.hex 260710initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710scrub.hex 260710scrub.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710readback.hex 260710readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710framefiles.tar.gz 260710framefiles.tar.gz]<br> =====LSR_TRG 301109===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109initconf.hex lsr_trg301109initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109scrub.hex lsr_trg301109scrub.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109readback.hex lsr_trg301109readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109framefiles.tar.gz lsr_trg301109framefiles.tar.gz]<br> =====GPulser 301109===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserinitconf.hex 240310gpulserinitconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserscrub.hex 240310gpulserscrub.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserreadback.hex 240310gpulserreadback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserframefiles.tar.gz 240310gpulserframefiles.tar.gz]<br> [[User:Dfe002|Dominik]] 11:42, 23 August 2010 (UTC) 3c82024eef9f4cfb275461941fed59442b1afa68 1272 1271 2010-08-24T07:45:51Z Dfe002 7 removed wrong files wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: # Load the bit-file for the FPGA # Type the name of the device as you can see above in “DeviceName” # Load the XML configuration file # Type the directory where the frames are saved to # Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. ===Download Section=== ====Program, libraries and instructions==== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/BitGui.zip BitGui.zip] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Linux.tar.gz generateConfigFiles_Linux.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/generateConfigFiles_Windows.rar generateConfigFiles_Windows.rar] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtCore.tar.gz libQtCore.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtGUI.tar.gz libQtGUI.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/psa3.pdf Internship Report] | ====Firmware packages==== =====RCU 260710===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710initconf.hex 260710initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710scrub.hex 260710scrub.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710readback.hex 260710readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710framefiles.tar.gz 260710framefiles.tar.gz]<br> =====LSR_TRG 301109===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109initconf.hex lsr_trg301109initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109readback.hex lsr_trg301109readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109framefiles.tar.gz lsr_trg301109framefiles.tar.gz]<br> =====GPulser 301109===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserinitconf.hex 240310gpulserinitconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserreadback.hex 240310gpulserreadback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserframefiles.tar.gz 240310gpulserframefiles.tar.gz]<br> [[User:Dfe002|Dominik]] 11:42, 23 August 2010 (UTC) 35326aa6b186c8edc08c4d4eff77ba44765e6dfe 1337 1272 2010-09-16T10:51:48Z Dfe002 7 updated file links wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: # Load the bit-file for the FPGA # Type the name of the device as you can see above in “DeviceName” # Load the XML configuration file # Type the directory where the frames are saved to # Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. ===Download Section=== ====Program, libraries and instructions==== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/BitGui_Linux.tar.gz BitGui_Linux.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtCore.tar.gz libQtCore.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtGUI.tar.gz libQtGUI.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/psa3.pdf Internship Report] | ====Firmware packages==== =====RCU 260710===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710initconf.hex 260710initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710scrub.hex 260710scrub.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710readback.hex 260710readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/rcu/260710framefiles.tar.gz 260710framefiles.tar.gz]<br> =====LSR_TRG 301109===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109initconf.hex lsr_trg301109initconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109readback.hex lsr_trg301109readback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/lsr_trg/lsr_trg301109framefiles.tar.gz lsr_trg301109framefiles.tar.gz]<br> =====GPulser 301109===== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserinitconf.hex 240310gpulserinitconf.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserreadback.hex 240310gpulserreadback.hex]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/fw/gpulser/240310gpulserframefiles.tar.gz 240310gpulserframefiles.tar.gz]<br> [[User:Dfe002|Dominik]] 11:42, 23 August 2010 (UTC) 7656bad4f8ff79c21c41bc0be617176b1023c4db 1338 1337 2010-09-16T11:03:19Z Dfe002 7 removed old files wikitext text/x-wiki ==Frame Generation Tool== ===General=== This tool can be used to generate frames for any Xilinx Virtex-II Pro FPGA. Therefore an XML based configuration file exists. To generate frame files the type of FPGA has to be added to the XML file. This is done in the following way:<br> <Device DeviceName="XC2VP7" DeviceID="0124A093" numFrames="1320" frameLength="106" IOBColumns="2" IOBFrames="4" IOIColumns="2" IOIFrames="22" CLBColumns="34" CLBFrames="22" BRAMColumns="6" BRAMFrames="64" BRAMICColumns="6" BRAMICFrames="22" GCLKColumns="1" GCLKFrames="4"><br> The device name can be found directly on the chip. The other values are provided in the Xilinx User Guide in the chapter “Configuration – Configuration Details”. There you will find two tables in which all frame and column sizes are listed. The device IDs you will also find in a table in this chapter. For different types of Virtex FPGAs the names of the frame types can vary. The names shown above are an example for Virtex-II Pro frames. <br> ===Creating frames=== Generating the frames is done in these steps: # Load the bit-file for the FPGA # Type the name of the device as you can see above in “DeviceName” # Load the XML configuration file # Type the directory where the frames are saved to # Press the “Split” button If the frames were generated successfully or an error occurred you will see a message. ===Creating binary command blocks=== This part can be found on the second tab on the right side. To create these command blocks just follow the steps 1-3 above. After you have done this enter the name (and path) of the command file and press the “Generate ...” button right beside. If the block was generated successfully or an error occurred you will see a message.<br> <br> ===Uploading to a dedicated location=== To load the files that were generated to the place they are needed an uploading feature was introduced. Here you enter the hostname to where you want to load the files up. Authenticating at the host is done by entering username and password. After that you are able to specify a local file/folder that has to be loaded up and a remote directory where the files/folder is saved to.<br><br> ===NOTE=== The remote directory must exist and local directories that contain subdirectories can not be loaded up<br> E.g. you want to load the files to “/tmp/test” the “test” directory has to be created before uploading. ===Download Section=== ====Program, libraries and instructions==== [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/BitGui_Linux.tar.gz BitGui_Linux.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtCore.tar.gz libQtCore.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/libQtGUI.tar.gz libQtGUI.tar.gz] | [http://web.ift.uib.no/~dominik/files/detectorlabwiki/bitgui/psa3.pdf Internship Report] | ====Firmware packages==== to come [[User:Dfe002|Dominik]] 11:03, 16 September 2010 (UTC) a7b8c430cc3de52c96206232ec5388c735c3860d 0 222 1273 754 2010-09-02T15:15:58Z Ako054 44 wikitext text/x-wiki == ASIM - Atmosphere Space Interaction Monitor == ASIM is an experiment for the International Space Station (ISS) external facilities on the Columbus module. ASIM is aimed at the study of high-altitude optical emissions from the stratosphere and mesosphere, the Transient Luminous Events (TLEs: Red Sprites, Blue Jets, Elves) and the Terrestrial Gamma Flashes (TGFs) (Neubert et al., 2006). ASIM has been through a Phase-A (Development and Design, 2004-2005) and a Phase-B (Breadboard and Feasibility, 2007-2009) study. In May 2009 the Program Board for Human Spaceflight and Exploration (PB-HME) decided that the ASIM payload shall be part of the ELIPS-3 program and allocated funding to ASIM from the program. A flight model of the ASIM payload will be built through Phase C/D starting early 2010. ---- [[ASIM-BGO]] [[ASIM-CZT]] [[Category:Space physics]] add19833edb2134b2630cfda6b4659950caa047b 1275 1273 2010-09-02T15:24:10Z Ako054 44 wikitext text/x-wiki == ASIM - Atmosphere Space Interaction Monitor == ASIM is an experiment for the International Space Station (ISS) external facilities on the Columbus module. ASIM is aimed at the study of high-altitude optical emissions from the stratosphere and mesosphere, the Transient Luminous Events (TLEs: Red Sprites, Blue Jets, Elves) and the Terrestrial Gamma Flashes (TGFs) (Neubert et al., 2006). ASIM has been through a Phase-A (Development and Design, 2004-2005) and a Phase-B (Breadboard and Feasibility, 2007-2009) study. In May 2009 the Program Board for Human Spaceflight and Exploration (PB-HME) decided that the ASIM payload shall be part of the ELIPS-3 program and allocated funding to ASIM from the program. A flight model of the ASIM payload will be built through Phase C/D starting early 2010. ---- [[ASIM-BGO]] [[ASIM-CZT]] [[Category:Space physics]] 66e05740fcda9ea40eb5a7fd6345c61f7225568e 14 303 1276 2010-09-02T15:25:04Z Ako054 44 Created page with ' [[Category:Space physics]]' wikitext text/x-wiki [[Category:Space physics]] 40b9e39ddb6e0b105a215d7ad87854c1437f7c39 0 304 1277 2010-09-02T15:28:37Z Ako054 44 Created page with '==CZT detector== CZT stands for [[http://en.wikipedia.org/wiki/Cadmium_zinc_telluride|Cadmium Zinc Telluride]], a semiconductor material. In ASIM context CZT is also the MXGS de…' wikitext text/x-wiki ==CZT detector== CZT stands for [[http://en.wikipedia.org/wiki/Cadmium_zinc_telluride|Cadmium Zinc Telluride]], a semiconductor material. In ASIM context CZT is also the MXGS detector with imaging capability. [[Category:ASIM]] 0e5ba61d785ce3a849a87615a17dbc903de79467 1278 1277 2010-09-02T15:29:20Z Ako054 44 wikitext text/x-wiki ==CZT detector== CZT stands for [http://en.wikipedia.org/wiki/Cadmium_zinc_telluride| Cadmium Zinc Telluride], a semiconductor material. In ASIM context CZT is also the MXGS detector with imaging capability. [[Category:ASIM]] c266ec10a58c8ce6ac1fbb7edb5779ef4d153c96 0 25 1290 1219 2010-09-07T12:30:48Z Ako054 44 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[HTL Designer]] lage firmware [[Category:Mikroelektronikk]] aa9c422cfaff4115b23a337c74da2cc63fe4e7fd 1291 1290 2010-09-07T12:31:17Z Ako054 44 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[HDL Designer]] lage firmware [[Category:Mikroelektronikk]] ae298bfc25acd9889a54dae567468716d8027eb4 0 203 1294 1238 2010-09-09T07:58:09Z Dfe002 7 added new info wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". There is a CERN shuttle bus to/from the airport ([https://espace.cern.ch/info-RegularShuttleService/default.aspx timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 15:56, 22 March 2010 (UTC) 8674753e6c86da0eb29de705d81a1a0d515fde8c 0 202 1297 759 2010-09-13T07:39:50Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] * [[http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets]] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV]] [[Category:Mikroelektronikk]] 19e36db06dbbb1641581bfe1bdb8e305ecd52fea 0 21 1314 1232 2010-09-14T10:42:49Z Dfe002 7 /* Our projects */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Jostein, Camilla, Kristian, Per-Ivar * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 10.05. - 14.05.10: The XIV International Conference on Calorimetry in High Energy Physics - Calor2010, Beijing, China, http://bes3.ihep.ac.cn/conference/calor2010/ * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany == For internal use == [[material]] that can be used in official presentations. d3e7dea3e694db1922ffff73989fdb6fb2253c2e 1324 1314 2010-09-14T12:43:03Z Jsa038 34 Removed Jostein from the student list. This list should be updated. wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Hege, Kristine, Njål, Stian, Lars-Halvard, Andreas, Camilla, Kristian, Per-Ivar * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 10.05. - 14.05.10: The XIV International Conference on Calorimetry in High Energy Physics - Calor2010, Beijing, China, http://bes3.ihep.ac.cn/conference/calor2010/ * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany == For internal use == [[material]] that can be used in official presentations. a2e49359b32a7970b8879fd41a73594b60e960ce 6 307 1315 2010-09-14T11:56:25Z Plo054 39 The objective of this thesis was to characterize the MAPD3-N photodetector from Zecotek Photonics. The main parameters that have been characterized are the Absolute Gain, Photon Detection Efficiency (PDE) or spectral response, Dark current and the gain as a function of the temperature and bias voltage of the detector. wikitext text/x-wiki The objective of this thesis was to characterize the MAPD3-N photodetector from Zecotek Photonics. The main parameters that have been characterized are the Absolute Gain, Photon Detection Efficiency (PDE) or spectral response, Dark current and the gain as a function of the temperature and bias voltage of the detector. 9e6e0d03c2a5a3550b5793ba4e91d9289d440052 0 211 1316 707 2010-09-14T11:59:25Z Plo054 39 wikitext text/x-wiki Feel free to add thesis/articles! ==Masterthesis== *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] *[https://wikihost.uib.no/ift/images/f/f4/L%C3%B8nne_MAPD3-N.pdf Per-Ivar Lønne: Characterization of The MAPD3-N Multipixel Avalanche Photodiode, August 2010] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout, 2008] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier, 2001] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems, 2009] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation, 2004] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies), 2009] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics, 2007] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging, 2002] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection, 1996] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter, 2008] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] '''PET''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1239645&isnumber=27794 Advantages of improved timing accuracy in PET cameras using LSO scintillator, 2002] *[http://www.iop.org/EJ/article/0031-9155/50/19/006/1.pdf First experimental results of time-of-flight reconstruction on an LSO PET scanner, 2005] *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=775565&isnumber=16852 Prospects for time-of-flight PET using LSO scintillator, 1999] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4P2S8W2-9-3&_cdi=5314&_user=107896&_orig=search&_coverDate=10%2F01%2F2007&_sk=994199997&view=c&wchp=dGLbVlz-zSkzk&md5=b4f9d0ef3f0dfb31a54c6c8dba480178&ie=/sdarticle.pdf Recent advances and future advances in time-of-flight PET, 2007] 5ed249df591739d55b80cd9825a4e505969026a2 1327 1316 2010-09-14T12:59:53Z Jsa038 34 Added Jostein's master thesis wikitext text/x-wiki Feel free to add thesis/articles! ==Masterthesis== *[https://wikihost.uib.no/ift/index.php/File:Characterization_of_Scintillation_Crystals_for_Positron_Emission_Tomography.pdf Jostein Sæterstøl: Characterization of Scintillation Crystals for Positron Emission Tomography, June 2010] *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] *[https://wikihost.uib.no/ift/images/f/f4/L%C3%B8nne_MAPD3-N.pdf Per-Ivar Lønne: Characterization of The MAPD3-N Multipixel Avalanche Photodiode, August 2010] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout, 2008] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier, 2001] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems, 2009] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation, 2004] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies), 2009] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics, 2007] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging, 2002] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection, 1996] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter, 2008] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] '''PET''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1239645&isnumber=27794 Advantages of improved timing accuracy in PET cameras using LSO scintillator, 2002] *[http://www.iop.org/EJ/article/0031-9155/50/19/006/1.pdf First experimental results of time-of-flight reconstruction on an LSO PET scanner, 2005] *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=775565&isnumber=16852 Prospects for time-of-flight PET using LSO scintillator, 1999] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4P2S8W2-9-3&_cdi=5314&_user=107896&_orig=search&_coverDate=10%2F01%2F2007&_sk=994199997&view=c&wchp=dGLbVlz-zSkzk&md5=b4f9d0ef3f0dfb31a54c6c8dba480178&ie=/sdarticle.pdf Recent advances and future advances in time-of-flight PET, 2007] a2c7fd9a04e8bc1a667dc03f9fb5ea9cb56c9cbb 1328 1327 2010-09-14T13:15:35Z Dfe002 7 changed link to Josteins thesis wikitext text/x-wiki Feel free to add thesis/articles! ==Masterthesis== *[https://wikihost.uib.no/ift/images/c/c2/Characterization_of_Scintillation_Crystals_for_Positron_Emission_Tomography.pdf Jostein Sæterstøl: Characterization of Scintillation Crystals for Positron Emission Tomography, June 2010] *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] *[https://wikihost.uib.no/ift/images/f/f4/L%C3%B8nne_MAPD3-N.pdf Per-Ivar Lønne: Characterization of The MAPD3-N Multipixel Avalanche Photodiode, August 2010] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout, 2008] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier, 2001] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems, 2009] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation, 2004] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies), 2009] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics, 2007] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging, 2002] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection, 1996] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter, 2008] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] '''PET''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1239645&isnumber=27794 Advantages of improved timing accuracy in PET cameras using LSO scintillator, 2002] *[http://www.iop.org/EJ/article/0031-9155/50/19/006/1.pdf First experimental results of time-of-flight reconstruction on an LSO PET scanner, 2005] *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=775565&isnumber=16852 Prospects for time-of-flight PET using LSO scintillator, 1999] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4P2S8W2-9-3&_cdi=5314&_user=107896&_orig=search&_coverDate=10%2F01%2F2007&_sk=994199997&view=c&wchp=dGLbVlz-zSkzk&md5=b4f9d0ef3f0dfb31a54c6c8dba480178&ie=/sdarticle.pdf Recent advances and future advances in time-of-flight PET, 2007] 1a25d7d6ccb96a3386de7ab9ac2ab0197a67884a 1329 1328 2010-09-14T13:17:16Z Dfe002 7 changed order of thesis so that newest is on top wikitext text/x-wiki Feel free to add thesis/articles! ==Masterthesis== *[https://wikihost.uib.no/ift/images/f/f4/L%C3%B8nne_MAPD3-N.pdf Per-Ivar Lønne: Characterization of The MAPD3-N Multipixel Avalanche Photodiode, August 2010] *[https://wikihost.uib.no/ift/images/c/c2/Characterization_of_Scintillation_Crystals_for_Positron_Emission_Tomography.pdf Jostein Sæterstøl: Characterization of Scintillation Crystals for Positron Emission Tomography, June 2010] *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout, 2008] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier, 2001] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems, 2009] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation, 2004] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies), 2009] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics, 2007] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging, 2002] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection, 1996] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter, 2008] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] '''PET''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1239645&isnumber=27794 Advantages of improved timing accuracy in PET cameras using LSO scintillator, 2002] *[http://www.iop.org/EJ/article/0031-9155/50/19/006/1.pdf First experimental results of time-of-flight reconstruction on an LSO PET scanner, 2005] *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=775565&isnumber=16852 Prospects for time-of-flight PET using LSO scintillator, 1999] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4P2S8W2-9-3&_cdi=5314&_user=107896&_orig=search&_coverDate=10%2F01%2F2007&_sk=994199997&view=c&wchp=dGLbVlz-zSkzk&md5=b4f9d0ef3f0dfb31a54c6c8dba480178&ie=/sdarticle.pdf Recent advances and future advances in time-of-flight PET, 2007] 0a8a622a7946dfc1e658043e060cbc86e9971f5b 1332 1329 2010-09-14T14:40:26Z Dfe002 7 added Andreas Samnøys master thesis wikitext text/x-wiki Feel free to add thesis/articles! ==Masterthesis== *[https://wikihost.uib.no/ift/images/f/f4/L%C3%B8nne_MAPD3-N.pdf Per-Ivar Lønne: Characterization of The MAPD3-N Multipixel Avalanche Photodiode, August 2010] *[https://wikihost.uib.no/ift/images/5/52/Master_Thesis_by_Andreas_Tefre_Samn%C3%B8y.pdf Andreas Tefre Samnøy: Automated XY-table for the characterisation of arrays of pixel sensors for photons and charge particles, June 2010] *[https://wikihost.uib.no/ift/images/c/c2/Characterization_of_Scintillation_Crystals_for_Positron_Emission_Tomography.pdf Jostein Sæterstøl: Characterization of Scintillation Crystals for Positron Emission Tomography, June 2010] *[https://wikihost.uib.no/ift/images/7/79/Characterization_of_Multipixel_Avalanche_Photodiodes.pdf Hege Austrheim Erdal: Characterization of Multipixel Avalanche Photodiodes, Spring 2009] ==Articles== '''MAPDs''' *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4K8R2VD-3-1&_cdi=5314&_user=107896&_orig=search&_coverDate=11%2F01%2F2006&_sk=994329998&view=c&wchp=dGLzVtb-zSkWb&md5=9c5649af6fe6c5760e2817ec59212e5f&ie=/sdarticle.pdf Three advanced designs of micro-pixel avalanche photodiodes: Their present status, maximum possibilities and limitations, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-5-B&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLbVzz-zSkWb&md5=135ecb8f64afb68d93ab23ec6bd216f4&ie=/sdarticle.pdf Longitudinally segmentednext term lead/scintillator hadron calorimeter with micro-pixel APD readout, 2008] *[http://www.gsi.de/documents/DOC-2006-Jan-140-1.pdf Very Forward Hadron Calorimeter for the CBM Experiment - Projectile Spectator Detector (PSD), 2006] *[http://sunhe.jinr.ru/struct/neeo/apd/Publications/talk-Beaune-05.pdf Talk: Three advanced designs of avalanche micro-pixel photodiodes: their history of development, present status, maximum possibilities and limitations, Beaune 05] *[http://www.ihep.su/ihep/doc_seminar/LINC-2008/2008_06_19/Sadovsky.A.pdf Talk: Hadron Calorimeters with micropixel APD readout for heavy ion experiment, Protvino 08] '''SiPMs''' *[http://www.slac.stanford.edu/pubs/icfa/fall01/paper3/paper3.pdf An advanced study of Silicon Photomultiplier, 2001] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4VM43VS-2&_user=107896&_coverDate=06%2F01%2F2009&_alid=998027297&_rdoc=3&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=7&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f3f8bf5da5da970b345625217393aa74 Novel photo-detectors and photo-detector systems, 2009] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4BT3HYY-5S&_user=107896&_coverDate=02%2F01%2F2004&_alid=998028955&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=2cc5fcfe7bb0d05500b009323f28218e Novel type of avalanche photodetector with Geiger mode operation, 2004] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4FY9J4V-5-32&_cdi=5314&_user=107896&_orig=search&_coverDate=06%2F21%2F2005&_sk=994549996&view=c&wchp=dGLbVzb-zSkWz&md5=e131c2f407708a80fb1cd6da07e891a7&ie=/sdarticle.pdf A test of silicon photomultipliersnext term as readout for PET, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4JJGFF4-3&_user=107896&_coverDate=07%2F15%2F2006&_alid=998042379&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_sort=r&_docanchor=&view=c&_ct=5&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=59c6858cad55abfed42517419cd2bd04 Status report on silicon photomultiplier development and its applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4DKD10G-2-1&_cdi=5314&_user=107896&_orig=search&_coverDate=02%2F11%2F2005&_sk=994619998&view=c&wchp=dGLbVlb-zSkzk&md5=f9fc5f4683be4f6c50888102c9516b72&ie=/sdarticle.pdf Comparison of a silicon photomultiplier to a traditional vacuum photomultiplier, 2005] *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4K5SS0T-P&_user=107896&_coverDate=11%2F01%2F2006&_alid=998044663&_rdoc=1&_fmt=high&_orig=search&_cdi=5314&_docanchor=&view=c&_ct=3&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=f259adb2f5076fb2a7feaffd121314f7 Study of SiPM as a potential photodetector for scintillator readout, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0211.PDF The Calice Analog Scintillator-Tile Hadronic Calorimeter Prototype, 2006] *[http://www.slac.stanford.edu/econf/C0604032/papers/0018.pdf The Silicon Photomultiplier - A new device for High Energy Physics,. Astroparticle Physics, Industrial and Medical Applications, 2006] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4T7XGK5-3-J&_cdi=5314&_user=107896&_orig=search&_coverDate=01%2F01%2F2009&_sk=994019998&view=c&wchp=dGLzVtb-zSkzk&md5=59bbe4b777d393a7df923b76c9056751&ie=/sdarticle.pdf Advances in multipixel Geiger-mode avalanche photodiodes (silicon photomultiplies), 2009] '''MPPCs''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4436549&isnumber=4436479 Application of novel silicon-based photo-detector to calorimetry and medical physics, 2007] '''General about the photodetectors''' *[http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJC-4V75YSS-1&_user=107896&_coverDate=07%2F31%2F2009&_alid=998034945&_rdoc=1&_fmt=high&_orig=search&_cdi=5307&_sort=r&_docanchor=&view=c&_ct=4&_acct=C000008398&_version=1&_urlVersion=0&_userid=107896&md5=ae4ed67c38b723d3d5c531a8ebbdc593 Very nice -> Silicon detector systems in high energy physics, 2009] *[http://www.ll.mit.edu/publications/journal/pdf/vol13_no2/13_2geigermode3d.pdf Geiger-Mode Avalanche Photodiodes for Three-Dimensional Imaging, 2002] *[http://www.opticsinfobase.org/viewmedia.cfm?uri=ao-35-12-1956&seq=0 Avalanche photodiodes and quenching circuits for single-photon detection, 1996] *[http://pdg.lbl.gov/2006/reviews/passagerpp.pdf Passage of particles through matter, 2008] *[http://breast.lbl.gov/~wwwinstr/publications/Papers/LBNL-51197.pdf Synergies between electromagnetic calorimetry and PET, 2002] '''PET''' *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1239645&isnumber=27794 Advantages of improved timing accuracy in PET cameras using LSO scintillator, 2002] *[http://www.iop.org/EJ/article/0031-9155/50/19/006/1.pdf First experimental results of time-of-flight reconstruction on an LSO PET scanner, 2005] *[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=775565&isnumber=16852 Prospects for time-of-flight PET using LSO scintillator, 1999] *[http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TJM-4P2S8W2-9-3&_cdi=5314&_user=107896&_orig=search&_coverDate=10%2F01%2F2007&_sk=994199997&view=c&wchp=dGLbVlz-zSkzk&md5=b4f9d0ef3f0dfb31a54c6c8dba480178&ie=/sdarticle.pdf Recent advances and future advances in time-of-flight PET, 2007] a7a71ac35b554a52148a8fe0eab19f319c6033da 0 308 1317 2010-09-14T12:00:25Z Ako054 44 Created page with '==BGO channel== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the…' wikitext text/x-wiki ==BGO channel== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 41d525125644fe70e9cea7554be091aa80bccac5 0 309 1319 2010-09-14T12:01:27Z Dfe002 7 initial version wikitext text/x-wiki == Goal == The aim of this phys117 course is to build a small array with 9 crystals coupled to silicon photo multipliers. For this we need to design the circuit to read out the MPPCs and include a pre amplifier there. We also need to have a light tight containment that holds the crystals and couples them to the MPPCs. To measure the physical crosstalk the crystals have to be individually wrapped. The readout of the whole system is then done in Labview through two 14 bit 2 Ghz oversampling CAEN ADCs. == Resources == c1a8c015f2d2e058a27e449cf25c62297436f122 1320 1319 2010-09-14T12:08:24Z Dfe002 7 added readout and preamp circuit schematics and layout wikitext text/x-wiki == Goal == The aim of this phys117 course is to build a small array with 9 crystals coupled to silicon photo multipliers. For this we need to design the circuit to read out the MPPCs and include a pre amplifier there. We also need to have a light tight containment that holds the crystals and couples them to the MPPCs. To measure the physical crosstalk the crystals have to be individually wrapped. The readout of the whole system is then done in Labview through two 14 bit 2 Ghz oversampling CAEN ADCs. == Resources == [http://web.ift.uib.no/~dominik/files/phys117/MPPC%20Amplifier.zip Eagle schematics and layout] [http://web.ift.uib.no/~dominik/files/phys117/Multisim.zip Multisim simulation model] 85d33ec93fd568c16ada06ccab88870493a2c4c9 1321 1320 2010-09-14T12:08:45Z Dfe002 7 fixed linebreak wikitext text/x-wiki == Goal == The aim of this phys117 course is to build a small array with 9 crystals coupled to silicon photo multipliers. For this we need to design the circuit to read out the MPPCs and include a pre amplifier there. We also need to have a light tight containment that holds the crystals and couples them to the MPPCs. To measure the physical crosstalk the crystals have to be individually wrapped. The readout of the whole system is then done in Labview through two 14 bit 2 Ghz oversampling CAEN ADCs. == Resources == [http://web.ift.uib.no/~dominik/files/phys117/MPPC%20Amplifier.zip Eagle schematics and layout]<br> [http://web.ift.uib.no/~dominik/files/phys117/Multisim.zip Multisim simulation model] ae9b9471480b30d5ea96898387b98ef901e7d56a 1348 1321 2010-09-21T09:42:25Z Dfe002 7 added link to preamp datasheet wikitext text/x-wiki == Goal == The aim of this phys117 course is to build a small array with 9 crystals coupled to silicon photo multipliers. For this we need to design the circuit to read out the MPPCs and include a pre amplifier there. We also need to have a light tight containment that holds the crystals and couples them to the MPPCs. To measure the physical crosstalk the crystals have to be individually wrapped. The readout of the whole system is then done in Labview through two 14 bit 2 Ghz oversampling CAEN ADCs. == Resources == [http://web.ift.uib.no/~dominik/files/phys117/MPPC%20Amplifier.zip Eagle schematics and layout]<br> [http://web.ift.uib.no/~dominik/files/phys117/Multisim.zip Multisim simulation model] [http://www.farnell.com/datasheets/92509.pdf AD8000YDZ preamp datasheet] 818b255af79d843b74a447d61f86a3bf555a8700 1349 1348 2010-09-21T09:42:39Z Dfe002 7 /* Resources */ wikitext text/x-wiki == Goal == The aim of this phys117 course is to build a small array with 9 crystals coupled to silicon photo multipliers. For this we need to design the circuit to read out the MPPCs and include a pre amplifier there. We also need to have a light tight containment that holds the crystals and couples them to the MPPCs. To measure the physical crosstalk the crystals have to be individually wrapped. The readout of the whole system is then done in Labview through two 14 bit 2 Ghz oversampling CAEN ADCs. == Resources == [http://web.ift.uib.no/~dominik/files/phys117/MPPC%20Amplifier.zip Eagle schematics and layout]<br> [http://web.ift.uib.no/~dominik/files/phys117/Multisim.zip Multisim simulation model]<br> [http://www.farnell.com/datasheets/92509.pdf AD8000YDZ preamp datasheet]<br> 36415c17a54999e1372560899d1ae3d7c3633fa1 6 311 1325 2010-09-14T12:46:07Z Jsa038 34 The main purpose of this thesis has been to characterize BGO and LYSO crystals of different sizes with respect to decay time and energy resolution. BGO crystals have been used as a reference material. The work presented here is part of a research project initiated by the Department of Physics and Technology, University of Bergen, and the Department of Radiology, Haukeland University Hospital. The project is entitled “Improved diagnostics in Positron Emission Tomography (PET) through the extraction of temporal characteristics from detector system and tissue.” The main objective of the project is to use temporal information to improve sensitivity and specificity in imaging with PET technology. For the BGO crystals, a decay time of 305 +/- 6 ns has been found. The energy resolution measured with the use of the best optical grease was 16.6 +/- 0.1%. Ten small (2x2x16 mm3) LYSO crystals have been found to have a decay time of 47.0 +/- 0.3 ns. The best obtained energy resolution for these crystals is 13.3 +/- 0.2%. The larger crystals generally show a somewhat longer decay time. The 5x5x20 mm3 crystals show decay times of 48.0 to 48.5 ns. Of the crystal sizes tested, the 5x5x20 mm3 crystals show the best energy resolution. With the use of optical grease, an energy resolution of 11.4 +/- 0.1% has been measured. The linearity of the energy spectra has been investigated by the use of two different radioactive sources with a total of three different energy peaks. The linearity is very good both for the BGO and LYSO crystals. A qualitative investigation of the interaction efficiency of LYSO crystals of different sizes has been performed. The number of counts in the photopeak is compared to the total number of counts in the spectrum. No apparent difference is found increasing crystal length. The thickness of the crystal influences the interaction efficiency greatly. In addition to the characterization of different crystals, an introductory experiment concerning the rate of single, random, and true counts as a function of the activity has been performed in the PET scanner at the PET centre at Haukeland University Hospital (HUH). wikitext text/x-wiki The main purpose of this thesis has been to characterize BGO and LYSO crystals of different sizes with respect to decay time and energy resolution. BGO crystals have been used as a reference material. The work presented here is part of a research project initiated by the Department of Physics and Technology, University of Bergen, and the Department of Radiology, Haukeland University Hospital. The project is entitled “Improved diagnostics in Positron Emission Tomography (PET) through the extraction of temporal characteristics from detector system and tissue.” The main objective of the project is to use temporal information to improve sensitivity and specificity in imaging with PET technology. For the BGO crystals, a decay time of 305 +/- 6 ns has been found. The energy resolution measured with the use of the best optical grease was 16.6 +/- 0.1%. Ten small (2x2x16 mm3) LYSO crystals have been found to have a decay time of 47.0 +/- 0.3 ns. The best obtained energy resolution for these crystals is 13.3 +/- 0.2%. The larger crystals generally show a somewhat longer decay time. The 5x5x20 mm3 crystals show decay times of 48.0 to 48.5 ns. Of the crystal sizes tested, the 5x5x20 mm3 crystals show the best energy resolution. With the use of optical grease, an energy resolution of 11.4 +/- 0.1% has been measured. The linearity of the energy spectra has been investigated by the use of two different radioactive sources with a total of three different energy peaks. The linearity is very good both for the BGO and LYSO crystals. A qualitative investigation of the interaction efficiency of LYSO crystals of different sizes has been performed. The number of counts in the photopeak is compared to the total number of counts in the spectrum. No apparent difference is found increasing crystal length. The thickness of the crystal influences the interaction efficiency greatly. In addition to the characterization of different crystals, an introductory experiment concerning the rate of single, random, and true counts as a function of the activity has been performed in the PET scanner at the PET centre at Haukeland University Hospital (HUH). 3fd95b65919160cfa57ad92625e1638331fe08ec 1326 1325 2010-09-14T12:57:45Z Jsa038 34 Protected "[[File:Characterization of Scintillation Crystals for Positron Emission Tomography.pdf]]" ([move=sysop] (indefinite)) wikitext text/x-wiki The main purpose of this thesis has been to characterize BGO and LYSO crystals of different sizes with respect to decay time and energy resolution. BGO crystals have been used as a reference material. The work presented here is part of a research project initiated by the Department of Physics and Technology, University of Bergen, and the Department of Radiology, Haukeland University Hospital. The project is entitled “Improved diagnostics in Positron Emission Tomography (PET) through the extraction of temporal characteristics from detector system and tissue.” The main objective of the project is to use temporal information to improve sensitivity and specificity in imaging with PET technology. For the BGO crystals, a decay time of 305 +/- 6 ns has been found. The energy resolution measured with the use of the best optical grease was 16.6 +/- 0.1%. Ten small (2x2x16 mm3) LYSO crystals have been found to have a decay time of 47.0 +/- 0.3 ns. The best obtained energy resolution for these crystals is 13.3 +/- 0.2%. The larger crystals generally show a somewhat longer decay time. The 5x5x20 mm3 crystals show decay times of 48.0 to 48.5 ns. Of the crystal sizes tested, the 5x5x20 mm3 crystals show the best energy resolution. With the use of optical grease, an energy resolution of 11.4 +/- 0.1% has been measured. The linearity of the energy spectra has been investigated by the use of two different radioactive sources with a total of three different energy peaks. The linearity is very good both for the BGO and LYSO crystals. A qualitative investigation of the interaction efficiency of LYSO crystals of different sizes has been performed. The number of counts in the photopeak is compared to the total number of counts in the spectrum. No apparent difference is found increasing crystal length. The thickness of the crystal influences the interaction efficiency greatly. In addition to the characterization of different crystals, an introductory experiment concerning the rate of single, random, and true counts as a function of the activity has been performed in the PET scanner at the PET centre at Haukeland University Hospital (HUH). 3fd95b65919160cfa57ad92625e1638331fe08ec 6 312 1331 2010-09-14T14:38:58Z Dfe002 7 Master Thesis by Andreas Tefre Samnøy wikitext text/x-wiki Master Thesis by Andreas Tefre Samnøy 14d6e303de47d297175d9321f9dbe083e9d31e76 6 313 1335 2010-09-14T14:48:26Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 315 1353 2010-09-28T14:35:05Z Ako054 44 Created page with '==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it…' wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls b4c0ebfc15e1927654f77ba56ac18ed3a5c7cfae 1354 1353 2010-09-28T16:30:08Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> entity nand2 is port(a,b: in std logic; q: out std_logic); end nand2; architecture basic of nand2 is q <= a nand b after 2 ns; end architecture nand2; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is signal int_en : std:logic; sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb); end architecture srlatch </pre> 0c89a73ef8ee66a42ea052654356b1f13f448dd9 1355 1354 2010-09-28T16:31:16Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> entity nand2 is port(a,b: in std logic; q: out std_logic); end nand2; architecture basic of nand2 is q <= a nand b after 2 ns; end architecture nand2; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture srlatch </pre> 34016e732cd1b3914449044f081dd7b51642a8d5 1356 1355 2010-09-28T17:50:22Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> d1814255c8b50af8ef8f8b01041c58cdd7c4372c 1357 1356 2010-09-29T09:41:49Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> 0c15c99ed8bd5465b66c79b9817fce62ad2c1527 1358 1357 2010-09-29T13:29:46Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== <pre> procedure proc_name is variable total : real :=0.0; begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </per> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> 132ab5b9fc442d0ac1694cd903740ff82005acd6 0 315 1359 1358 2010-09-29T13:30:29Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== <pre> procedure proc_name is variable total : real :=0.0; begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </pre> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> f0332db8dedeb1b08e1cb9cc45ddd840df567fc3 1360 1359 2010-09-29T13:55:01Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== variables etc. defined in the header are local variables. <pre> procedure proc_name is variable total : real :=0.0; --this is a local variable! begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </pre> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. ====package declaration==== the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. it defines the interface to a package. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> ====package body==== no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations. items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly. ===components=== f09e1dc71326a555d203d79c89d4add703079562 1361 1360 2010-09-29T14:10:18Z Ako054 44 /* components */ wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== variables etc. defined in the header are local variables. <pre> procedure proc_name is variable total : real :=0.0; --this is a local variable! begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </pre> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. ====package declaration==== the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. it defines the interface to a package. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> ====package body==== no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations. items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly. ===components=== to build hierarchical designs, used to describe interconnections in subsystems in a design. component declarations are written in the declarative part of the architecture (before the '''''begin'''''). bafc2dad4dc1727a62bfbd8128af7dcd80268aa2 1362 1361 2010-09-29T14:27:33Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== variables etc. defined in the header are local variables. <pre> procedure proc_name is variable total : real :=0.0; --this is a local variable! begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </pre> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. ====package declaration==== the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. it defines the interface to a package. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> ====package body==== no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations. items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly. ===components=== to build hierarchical designs, used to describe interconnections in subsystems in a design. component declarations are written in the declarative part of the architecture (before the ''begin''). it is an alternative to use entity declarations (see structural design). an entity declaration defines a real module, it's a separate design. a component declaration defines a virtual module in the architecture body. "for this architecture we assume there is a module specified by this component". 4f00112cef7b274b298bb4d94818581652628d66 1364 1362 2010-10-01T12:31:01Z Ako054 44 /* components */ wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== variables etc. defined in the header are local variables. <pre> procedure proc_name is variable total : real :=0.0; --this is a local variable! begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </pre> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. ====package declaration==== the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. it defines the interface to a package. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> ====package body==== no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations. items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly. ===components=== to build hierarchical designs, used to describe interconnections in subsystems in a design. component declarations are written in the declarative part of the architecture (before the ''begin''). it is an alternative to use entity declarations (see structural design). an entity declaration defines a real module, it's a separate design. a component declaration defines a virtual module in the architecture body. "for this architecture we assume there is a module specified by this component". ===configurations=== in a configuration file the declaration can be made in which case which entity is using which architecture. the architectures may vary e.g. in case of simulation or synthesis. A '''configuration declaration''' is a design unit which can be compiled separately. In a configuration declaration the binding of all components which are part of a certain entity can be specified. <pre> configuration config_identifier of entity_name is for architecture_name for all : component_identifier use entity lib_name.entity_name2(architecture_name2); --binding_indication end for; for bgo_channel_1 : bgo_channel use entity mxgs_bgo_lib.bgo_channel(struct) generic map( g_bgo_channel => "01" ); end for; end for; end config_identifier; </pre> 50ce62d96a0e9f138e79dcb11d7eb86ffc5c6e5d 1365 1364 2010-10-01T13:15:12Z Ako054 44 wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== variables etc. defined in the header are local variables. <pre> procedure proc_name is variable total : real :=0.0; --this is a local variable! begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </pre> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. ====package declaration==== the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. it defines the interface to a package. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> ====package body==== no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations. items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly. ===components=== to build hierarchical designs, used to describe interconnections in subsystems in a design. component declarations are written in the declarative part of the architecture (before the ''begin''). it is an alternative to use entity declarations (see structural design). an entity declaration defines a real module, it's a separate design. a component declaration defines a virtual module in the architecture body. "for this architecture we assume there is a module specified by this component". ===configurations=== in a configuration file the declaration can be made in which case which entity is using which architecture. the architectures may vary e.g. in case of simulation or synthesis. A '''configuration declaration''' is a design unit which can be compiled separately. In a configuration declaration the binding of all components which are part of a certain entity can be specified. also generic maps can be set. <pre> configuration config_identifier of entity_name is for architecture_name for all : component_identifier use entity lib_name.entity_name2(architecture_name2); --binding_indication end for; for bgo_channel_1 : bgo_channel use entity mxgs_bgo_lib.bgo_channel(struct) generic map( g_bgo_channel => "01" ); end for; end for; end config_identifier; </pre> 812fe920cd7b577c1e70bcd5ce0ab57f39ac7679 0 308 1366 1317 2010-10-01T13:26:50Z Ako054 44 /* temperature monitor */ wikitext text/x-wiki ==BGO channel== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_bin) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 2941f7b6edb3a34ce1e3d1c4be1754208156f33b 1367 1366 2010-10-01T13:27:10Z Ako054 44 /* temperature monitor */ wikitext text/x-wiki ==BGO channel== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 187c8fe35a5efd35c84af13aa7378c81952a3aa7 1368 1367 2010-10-13T14:11:56Z Ako054 44 /* Address decoder */ wikitext text/x-wiki ==BGO channel== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' memadr_in (from dpu_if/user) memdat_out_X (from modules) clk etc. '''output: ''' memadr_out (to modules) di_memdat_in (to dpu_if) * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 927bc689a4cea27af04e4ac80d1dbc29f19ea56e 1369 1368 2010-10-13T14:12:46Z Ako054 44 /* Address decoder */ wikitext text/x-wiki ==BGO channel== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) f9cd7b349a04b7b1914456707aceb05a3db57764 1370 1369 2010-10-13T14:13:02Z Ako054 44 /* Address decoder */ wikitext text/x-wiki ==BGO channel== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) d4395d2604c2dd57c6854b80f9d75cb145c9be36 1371 1370 2010-10-13T14:15:39Z Ako054 44 /* BGO channel */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) d58df4bbff1fde94ec5b7344a44134be4faefdc3 1372 1371 2010-10-13T14:16:01Z Ako054 44 /* MUX */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) a7195cc3a3bced2a98e820cb2cffbc548dab65a9 1373 1372 2010-10-13T14:16:21Z Ako054 44 /* Address decoder */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 97738f3870459f80466d732f7bf1d5242bfe4fdb 1374 1373 2010-10-13T14:17:28Z Ako054 44 /* Binning control module (BCM) */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 01da9773e86d379ffb64bc915bb341a8ddb84b00 1375 1374 2010-10-13T14:17:53Z Ako054 44 /* DPU interface */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) c7c3c3c79761adf231f77b4c6197ee63fee28367 1376 1375 2010-10-13T14:18:10Z Ako054 44 /* Temperature monitor */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 8560394ec7105a64b760ccf36217ea940f523a59 1377 1376 2010-10-13T14:33:43Z Ako054 44 /* mb_if */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm. basically a translator. translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) cb406c34296199ca0415effce19ceaa78ec93d9d 1378 1377 2010-10-13T14:37:05Z Ako054 44 /* mb_if */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====mb_if==== Memory bus interface. including a control register and a fsm. basically a translator. translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) b39fca680985df0fbcee5f583b12d5297fd2f27f 1379 1378 2010-10-13T14:37:52Z Ako054 44 /* mb_if */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface=== ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) a921ab8cfc3a5f32c323c0016532a859acb97af9 1380 1379 2010-10-13T14:39:31Z Ako054 44 /* memory bus interface */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface (mb_if)=== see mb_if ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 6f990f3513ebf25b9e4b98f92978d0cbbbbe710a 1381 1380 2010-10-13T14:42:48Z Ako054 44 /* memory bus interface (mb_if) */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in BGO channel ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. * asim_common_lib * 2008 by yngve (auto) 01fe5c3f13ab5fde40e826c4b0d9b983aa8af548 1382 1381 2010-10-13T14:44:05Z Ako054 44 /* memory bus interface */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in BGO channel ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 9d7ce1e64e577fc98fa64cebdf823e9a68a0ee92 1383 1382 2010-10-13T14:44:18Z Ako054 44 /* memory bus interface */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in BGO channel ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===memory bus interface=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 794f13646ffa71ed249a7c27c0d41c34e59bc862 1384 1383 2010-10-13T14:44:42Z Ako054 44 /* memory bus interface */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in BGO channel ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 b51a97ba090cac5a77b1be208056bc0638170216 1385 1384 2010-10-13T14:45:57Z Ako054 44 /* memory bus interface (mb_if) */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29_3|mb_if ]] in Temperature Monitor ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 6b105478ad998718e52ace1542772f6ab47e6cf3 1386 1385 2010-10-13T14:46:20Z Ako054 44 /* Memory bus interface (mb_if) */ wikitext text/x-wiki ==BGO channel (bgo_channel_[0-2])== There are 3 BGO channels, each interfacing one PMT. Each BGO channel is hosting an own FIFO to store the event data. The readout of the fifos is controlled by the MUX block. ===PMT interface=== PMT = photo multiplyer tube Taks: collects the ADC data from the detector, creates science data packets (SCDP) ans stores the data in a fifo. tasks included: lowpass filter, offset correction, tail estimation, shaping, peak detect, trigger & control. * mxgs_bgo_lib * 2009 by yngve (auto) included blocks: ====pmt_if_ctrl==== is a fsm <pre> port ( arst_n : in std_logic; -- asynchronous reset rst : in std_logic; -- synchronous reset clk : in std_logic; diff_trig : in std_logic; -- differential trigger ovf : in std_logic; -- ADC overflow peak : in std_logic; -- peak found val_trig : in std_logic; -- value trigger fast : in std_logic; -- pulse ocurred on the tail of another pulse offset_lock : in std_logic; -- offset is found load : out std_logic; -- load scdp offset_en : out std_logic; -- offset enable acc_en : in std_logic; -- baseline correction enable hug : out std_logic; -- release the peak hold register par_clr : out std_logic; -- clear paralyzation flag inhibit : in std_logic; -- inhibit further triggers smalltrig_en : in std_logic; -- enable small triggers adc_en : out std_logic; -- ADC enable smpl_mode : in std_logic; -- direct sampling mode fifo_full : in std_logic; -- fifo full flag fifo_empty : in std_logic; -- fifo empty flag smpl_trig : out std_logic -- feedthrough of ADC data to FIFO ); </pre> ====Memory bus interface (mb_if)==== see [[#Memory_bus_interface_.28mb_if.29_3|mb_if ]] in Temperature Monitor ====mov_avrg and mov_avrg8==== moving avarage. is a type of finite impulse response filter used to analyze a set of data points by creating a series of averages of different subsets of the full data set. (http://en.wikipedia.org/wiki/Moving_average) ====tailgen==== pulse tail cancellation in order to reduction of systems dead time. several filters. two separate tail estimation filters are used to enable tail cancellation of several consecutive pule tails. they will be used alternately, outputs are summed. find document "BGO extention" written by yngve for further details. ====tailgen_ctrl==== is a fsm. selcting a trigger? output= 'tg_sel' being 0 or 1 ===FIFO=== stores SCDP per channel FIFO1k48 * mxgs_bgo_lib ==MUX (bgo_mux)== coordinates data which should be read out from fifos. ... interface to the 3 fifos included in BGO_channels * mxgs_bgo_lib * 2010 by magne (auto) <pre> port( arst_n : in std_logic; -- asynchronous reset clk : in std_logic; -- clock fifo_read : in std_logic; -- read fifo from current chain data_na : out std_logic; -- data not available ch1_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 1 ch2_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 2 ch3_data : in std_logic_vector ( 47 downto 0 ); -- scdp from chain 3 dout : out std_logic_vector ( 47 downto 0 ); -- arbitrated data sfifo_empty : in std_logic_vector (1 to 3); sfifo_read : out std_logic_vector (1 to 3) ); </pre> ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) general: * mxgs_bgo_lib * 2008 by yngve ==Binning control module (BCM) (bin_ctrl_module)== the BCM generates a 2D table out of SCDP coming from the pmt_if. the table includes temporal and spectral bins. time and energy value from the SCDP are analysed and assigned to a temporal and spectral bin. that binvalue then will be incremented. there are lower and higher bondaries for the spectral bin value. if the energy value in the SCDP is outside that boundaries it will be discarded. the spectral boundaries are configurable via the mb_if. -> some kind of filter * asim_common_lib included modules: ===scdp channel mux=== ===bin address generator=== ===bin access control=== ===swing buffer=== ===bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29_3|mb_if ]] in Temperature Monitor ==DPU interface (dpu_if)== is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Temperature monitor (tmon_struct)== used for temperature compensation and housekeeping controls external MUX and a ADC. ===temperature monitor=== General description : This module is designed to control an analog mux and an ADC to capture values from three different analog sources, in this case termistor values for temperature meseurements. This module connects to the standard internal bus interface in the CZT/BGO firmware. It controls an external analog MUX and an ADC to sample three analog values representing temperatures. when the ADC data in a channel passes a certain limit an alarm is set. the limit is set by the user in the interface via the control register (mb_if) * asim_common_lib ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) general: * asim_common_lib * by yngve 2008 aff8345cb5fbfe626ea100f9fed499fb4b2deeda 0 21 1387 1324 2010-10-18T07:16:56Z Dfe002 7 updated students wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Lars-Halvard, Andreas, Kristian, Eivind, Arild, Oliver * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 10.05. - 14.05.10: The XIV International Conference on Calorimetry in High Energy Physics - Calor2010, Beijing, China, http://bes3.ihep.ac.cn/conference/calor2010/ * 24.05. - 28.05.10: 17th IEEE NPSS Real Time Conference - RT2010, Lisboa, Portugal, Deadline 01.03.10. (http://rt2010.ipfn.ist.utl.pt/) * 20.09. - 24.09.10: TWEPP, RWTH Aachen, Germany == For internal use == [[material]] that can be used in official presentations. 356e379e1a1b46d87b8be3205d1ae0e258d2a7b6 1395 1387 2010-10-18T12:53:15Z Dfe002 7 /* Meetings and conferences */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Lars-Halvard, Andreas, Kristian, Eivind, Arild, Oliver * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 30.10. - 08.10.10: IEEE 2010 Nuclear Science Symposium and Medical Imaging Conference(http://www.nss-mic.org/2010/) == For internal use == [[material]] that can be used in official presentations. 16572a571ac28555a8801b54f86bf17c7feef530 0 111 1389 895 2010-10-18T10:19:19Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | |2x Anja |- |TTi EL302D |30V, 2A dual linear DC power supply | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 51f42cc9771bd4b906bd3355449b18ddc888f5f4 1390 1389 2010-10-18T10:20:20Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | |2x Anja |- |TTi EL302D |30V, 2A dual linear DC power supply | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | |- |ITT AX 322 |2x 30V, 2,5A | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} 06937310dc87e7aeaf0b6f70b9d50bfa56cc96f4 1391 1390 2010-10-18T10:22:48Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |USB, LabView |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |USB, Labview |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} c927a67d97f27b93f28f0f2e112aab98fe844388 1392 1391 2010-10-18T12:39:50Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} b02a0040d5a595a318f20d9675376676fbaa9752 1393 1392 2010-10-18T12:40:43Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, 5 Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} b99981fb417e835cb9fe4dfb99c5bbbe41874348 1394 1393 2010-10-18T12:44:53Z Dfe002 7 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Number !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |2 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |1 |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |1 |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |4 |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |2 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |1 |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |1 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, 5 Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} a3b1352d6a5dd5f77e02f2e285d41449a4b0b45d 0 304 1396 1278 2010-10-18T18:31:33Z Ako054 44 /* CZT detector */ wikitext text/x-wiki ==CZT detector== CZT stands for [http://en.wikipedia.org/wiki/Cadmium_zinc_telluride| Cadmium Zinc Telluride], a semiconductor material. In ASIM context CZT is also the MXGS detector with imaging capability. ==Firmware== An introduction to the CZT EBB firmware can be found here: [[CZT-firmware]] [[Category:ASIM]] 56055011c0145d0f4704328f26e524a4dfd216b0 0 316 1397 2010-10-18T18:35:06Z Ako054 44 Created page with 'List of included modules in hierachical order: ==Detector module interface (dm_if)== ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == ===xlink_rx=== ===rx register===…' wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == ===xlink_rx=== ===rx register=== ===xlink_tx=== ===tx register=== ===tx control fsm=== ==Address decoder (adrdec_bgo)== ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 27f4de16169261b06339fe9cebf7dec7dbdb0530 1398 1397 2010-10-18T18:35:37Z Ako054 44 /* Detector module interface (dm_if) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == ===xlink_rx=== ===rx register=== ===xlink_tx=== ===tx register=== ===tx control fsm=== ==Address decoder (adrdec_bgo)== ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 790fd99ec62ac3b80cd253da7ef5cce539c0463c 1399 1398 2010-10-18T18:41:51Z Ako054 44 /* Detector module interface (dm_if) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ==Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == ===xlink_rx=== ===rx register=== ===xlink_tx=== ===tx register=== ===tx control fsm=== ==Address decoder (adrdec_bgo)== ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 2aa6b5f750675d6485478c67e07eae68ea95fc7a 1400 1399 2010-10-18T18:47:47Z Ako054 44 /* XA config (xa_cfg) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ==Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == ===xlink_rx=== ===rx register=== ===xlink_tx=== ===tx register=== ===tx control fsm=== ==Address decoder (adrdec_bgo)== ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 1c5e6183b42549bcd4896a3a62a2db8519066b7c 1401 1400 2010-10-18T18:48:20Z Ako054 44 /* Hit discriminator (hit_dicr)= */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == ===xlink_rx=== ===rx register=== ===xlink_tx=== ===tx register=== ===tx control fsm=== ==Address decoder (adrdec_bgo)== ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 6ae10b4739de43ad1f87a0b8ea7fbcd7cb6b0f68 1402 1401 2010-10-18T18:49:28Z Ako054 44 /* Memory bus interface (mb_if) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == ===xlink_rx=== ===rx register=== ===xlink_tx=== ===tx register=== ===tx control fsm=== ==Address decoder (adrdec_bgo)== ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 06f2b522c6d826ea0dc61f4267dcb14afdade07b 1403 1402 2010-10-18T18:50:34Z Ako054 44 /* DPU interface (dpu_if) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 2c4e48ef04ed3b9e229ceca36f72d51aa15d9b4f 1404 1403 2010-10-18T18:51:25Z Ako054 44 /* Address decoder (adrdec_bgo) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules (pm_if_0, pm_if_1, pm_if_2, tmon or binctrl) * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 5b68c335160fe8be76e0a9beede283233aebb66c 1405 1404 2010-10-18T18:52:33Z Ako054 44 /* Address decoder (adrdec_bgo) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 77095918d9ece16e0d59f1ee27514a2add46bd43 1406 1405 2010-10-18T18:54:21Z Ako054 44 /* Binning control module (BCM) (bin_ctrl_module) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 1c7c1bb779c1ca289bd4373473168860c7abf329 1407 1406 2010-10-18T18:57:26Z Ako054 44 /* MUX (scdp_ch_mux) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== e0c0e85f8ee0e3aad309e67ccf0f2149dfa79904 1408 1407 2010-10-18T18:58:36Z Ako054 44 /* Memory bus interface (mb_if) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 37bb0ae351c98c8e54f2810f5ae2b76e1d320ec8 1409 1408 2010-10-18T18:58:43Z Ako054 44 /* Memory bus interface */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-4] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== 2a70bb762e67b0a334764a89a43079f71d7a8435 1410 1409 2010-10-18T19:05:48Z Ako054 44 /* Address decoder (adrdec_bgo) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''modules in control/status chain:''' * detector module interfaces (4 -- one per chain) * XA configuration (4 -- one per chain) * RCU master * bin control '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-9] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ===piso8_ctrl=== FSM ==Resync register== ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== d7047d049d031d02a04285ff7af14f42162448cd 0 316 1411 1410 2010-10-18T19:07:48Z Ako054 44 /* Resync register */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''modules in control/status chain:''' * detector module interfaces (4 -- one per chain) * XA configuration (4 -- one per chain) * RCU master * bin control '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-9] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ===piso8_ctrl=== FSM ==Resync register== synchronizes the inputs and outputs of the FPGA with the internal clock signal. ==Clock reset (clkrst)== ==Timetag generation (tt_gen)== c590091b86fbc0969d62355498ef3f79ac593d9e 1412 1411 2010-10-18T19:08:08Z Ako054 44 /* Clock reset (clkrst) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''modules in control/status chain:''' * detector module interfaces (4 -- one per chain) * XA configuration (4 -- one per chain) * RCU master * bin control '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-9] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ===piso8_ctrl=== FSM ==Resync register== synchronizes the inputs and outputs of the FPGA with the internal clock signal. ==Clock reset (clkrst)== This module generates the clock and the reset signal for the firmware components. The signals are based on a crystal oscillator input and a global clock. ==Timetag generation (tt_gen)== 536037a3ecdff8d2df086524be1457babbb2bd1c 1413 1412 2010-10-18T19:08:23Z Ako054 44 /* Timetag generation (tt_gen) */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''modules in control/status chain:''' * detector module interfaces (4 -- one per chain) * XA configuration (4 -- one per chain) * RCU master * bin control '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-9] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ===piso8_ctrl=== FSM ==Resync register== synchronizes the inputs and outputs of the FPGA with the internal clock signal. ==Clock reset (clkrst)== This module generates the clock and the reset signal for the firmware components. The signals are based on a crystal oscillator input and a global clock. ==Timetag generation (tt_gen)== The time tag generator provides information about when an event happens. It maintains a 20-bit counter used to timestamp science events. The 20-bit time stamp then become part of the science data package (SCDP) . eb0aae82f0eaa2fa794d416805f2d96b849d50e3 1414 1413 2010-10-18T19:10:44Z Ako054 44 /* LED control */ wikitext text/x-wiki List of included modules in hierachical order: ==Detector module interface (dm_if)== interface to readout electroncs for the detector modules. Reads energy, pixel and ASIC address, in addition to multihit information. Also controls the pipelined ADC. ===Offset substract=== Finds and subtracts the offset from ADC data, ensuring a consistent mean value of zero between all four detector chains ===Hit discriminator (hit_dicr)=== determines whether there was an event or not? ===Memory bus interface (mb_if)=== for communication with user interface. including a control register and a fsm. basically a translator, translating memory data into commands for active module and delivers status reports. '''input:''' * memory address memadr_in (from adress decoder) * memory data memdat_in (from address decoder, incl. command ) * status register sr[0-3] (from logic module, e.g. tmon) * clk etc. '''output:''' * memdat_out (to address decoder, incl. answer) * control registers cr[0-3] (to logig module, incl. command) ==MUX (scdp_ch_mux)== The chain multiplexer receives the SCDP from readout chains (one chain contains 8 ASICS, that are 1024 channel) and writes data into the FIFO ==FIFO== ==DPU interface (dpu_if) == is interfacing the DPU emulator, input: commands, output: data, status * asim_common_lib <pre> port ( clk : in std_logic; -- clock arst_n : in std_logic; -- asynchronous reset memdat_in : in std_logic_vector(7 downto 0); -- memory bus data input serial_data_in : in std_logic; -- serial data input serial_strobe_in : in std_logic; -- serial strobe input serial_data_out : out std_logic; -- serial data output serial_strobe_out : out std_logic; -- serial strobe output RnW : out std_logic; -- read / write control ld_memdat : out std_logic; -- load memory data memadr_out : out std_logic_vector(13 downto 0); -- memory address memdat_out : out std_logic_vector(7 downto 0); -- memory data scdp : in std_logic_vector(47 downto 0); -- scdp input enable : in std_logic; -- enable input from DPU fifo_empty : in std_logic; -- fifo empty indicator fifo_read : out std_logic; -- fifo read enable fifo_full : in std_logic := '0'); -- fifo full indicator </pre> ===receiving:=== ====xlink_rx==== Description: receiver for "xlink", a serial data strobe encoded point to -- point communications protocol for the ASIM MXGS ====rx register==== reception register for DPU interface ===transmission:=== ====xlink_tx==== fsm ====tx register==== transmission register for DPU interface ====tx control fsm==== ==Address decoder (adrdec_bgo)== memory bus address decoder and data multiplexor * decodes the memory_address_in (memadr_in) and delivers data to called modules * the module_base address (e.g. tmon_base) is defined in the mxgs_bgo_pk package. * delivers answer (memdat, memory data) from modules '''modules in control/status chain:''' * detector module interfaces (4 -- one per chain) * XA configuration (4 -- one per chain) * RCU master * bin control '''input: ''' * memadr_in (from dpu_if/user) * memdat_out_[0-9] (from modules) * clk etc. '''output: ''' * memadr_out (to modules) * di_memdat_in (to dpu_if) ==Binning control module (BCM) (bin_ctrl_module) == The BCM delivers status reports of the collected data. It generates a 2D table out of SCDP coming from the pmt_if. This table includes temporal and spectral bins. Time and energy value from the SCDP are analyzed and assigned to a temporal and spectral bin. That bin value then will be incremented. There are lower and higher boundaries for the spectral bin value. If the energy value in the SCDP is outside the boundaries it will be discarded. The spectral boundaries are configurable via the mb_if. The result also is delivered via mb_if. ===Scdp channel mux=== ===Bin address generator=== ===Bin access control=== ===Swing buffer=== ===Bin module address arbiter=== ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==RCU master (rcumaster)== ===LED control=== FSM ===Memory bus interface (mb_if)=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ==XA config (xa_cfg)== ===XA register verification (xa_reg_verify)=== FSM, ASIC configuration register verifier ===RAM (dpram1k8)=== RAM to memorize control register, dual port RAM for volatile XA configuration data ===Memory bus interface=== see [[#Memory_bus_interface_.28mb_if.29|mb_if ]] in detector module interface ===piso8_ctrl=== FSM ==Resync register== synchronizes the inputs and outputs of the FPGA with the internal clock signal. ==Clock reset (clkrst)== This module generates the clock and the reset signal for the firmware components. The signals are based on a crystal oscillator input and a global clock. ==Timetag generation (tt_gen)== The time tag generator provides information about when an event happens. It maintains a 20-bit counter used to timestamp science events. The 20-bit time stamp then become part of the science data package (SCDP) . c9e5ae200e719a9ae3eb1f56da6f1b7b7657e136 0 2 1415 649 2010-11-10T16:58:29Z Dfe002 7 added focal section wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[FOCAL - Forward Calorimeter]] * [[PHOS PVSS panels]] * [[PHOS TOR]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Tips & Tricks corner]] * [[Coming to CERN]] <center>[[Image:alice.gif]]</center> bc6af98393faa7b62c0f898bffd604faa93e906a 1439 1415 2010-12-10T12:07:20Z Dfe002 7 wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[FOCAL - Forward Calorimeter]] * [[PHOS PVSS panels]] * [[PHOS TOR]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Coming to CERN]] <center>[[Image:alice.gif]]</center> c4d39310faa671270f477874f26b4836993471c1 1442 1439 2011-01-03T11:10:29Z Bwa021 51 added analysis topic wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[FOCAL - Forward Calorimeter]] * [[PHOS PVSS panels]] * [[PHOS TOR]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Analysis]] * [[Coming to CERN]] <center>[[Image:alice.gif]]</center> 28d0a56685e65943a92a1d5c25bc76cd54c594c0 0 317 1416 2010-11-10T17:00:12Z Dfe002 7 Created page with 'This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips =…' wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == 979fcfab019183a81a1c32b3a142261d3fcc971d 1418 1416 2010-11-19T12:00:07Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === First layout === == Download section == 652be70dceb3195900e5c834aee1c48aa95dc1e6 0 4 1417 1263 2010-11-12T12:32:58Z Dfe002 7 /* Updating the Actel Firmware */ wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> '''v 1.5 (17.08.2010)'''<br> <ul> <li>Fix done by Attiq Ur Rehman:<br> There is minor change in the "fifo wrapper":<br> Line #73 new signal cnt_dn<br> Line #91 comparison with "read_counter"<br> Line #170,172,174 check of possible logical conditions<br> This file was used for the RCU firmware (from 10th July and on wards) to fix the Erroneous behavior causing busy condition. </li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.5_source_files.rar Firmware v 1.5 - VHDL files, including testbench]<br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool]. Note that version 9.0 gives errors when trying to program the FPGA. [ftp://ftp.actel.com/downloads/flashpro/FlashPro86.zip Version 8.6] is the last version that works for the Actel on the RCU.<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 254d7a9aa7d992962035339ea09c7db5278a9883 0 318 1419 2010-11-25T13:13:44Z Asa022 21 Created page with 'XY-table, readout computer - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a na…' wikitext text/x-wiki XY-table, readout computer - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: Motor controller: SMC compact, uses Venus 1 command language. Motor stages: X, Y and Z direction Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. Fibremount: Device that mounts a fibre above the left microscope ocular. Fast LED pulser: Small analogue chip that pulses an attached LED *IMAGE* Sketch of XY-table === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. *IMAGE* Picture of XY-table == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. *Image* Fibremount == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file *Image* Position flash front panel. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. *Image* Place coords front panel The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. *Image* DAQ flowchart == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. 41c7d35bccaa350e49752c59fd5fb84423daaf91 1420 1419 2010-11-25T13:14:39Z Asa022 21 wikitext text/x-wiki XY-table, readout computer - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED *IMAGE* Sketch of XY-table === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. *IMAGE* Picture of XY-table == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. *Image* Fibremount == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file *Image* Position flash front panel. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. *Image* Place coords front panel The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. *Image* DAQ flowchart == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. f8e52eceacf981729051a663da855697e26f59c4 1427 1420 2010-11-29T09:49:51Z Asa022 21 wikitext text/x-wiki XY-table, readout computer - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED *IMAGE* Sketch of XY-table === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. [[File:setup with text.PNG]] == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. *Image* Fibremount == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file *Image* Position flash front panel. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. *Image* Place coords front panel The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. *Image* DAQ flowchart == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. 9f887a6422f71d9b80f45105d0cdcd1abb2a6780 1428 1427 2010-11-29T09:51:03Z Asa022 21 wikitext text/x-wiki XY-table, readout computer - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED [[File:start_sketch.pdf]] === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. [[File:setup with text.PNG]] == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. *Image* Fibremount == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file *Image* Position flash front panel. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. *Image* Place coords front panel The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. *Image* DAQ flowchart == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. 7ae2474208718a428f486ea5b58ed059a8d4fae0 1432 1428 2010-11-29T10:24:10Z Asa022 21 wikitext text/x-wiki XY-table, readout computer - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED [[File:start_sketch.png]] === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. [[File:setup with text.PNG]] == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. [[File:fibremount2.png]] == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file [[File:Position Flash front panel.PNG]] == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. [[File:Place Coords front panel.PNG]] The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. [[File:flowchart.png]] == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. 52ddaae36b1ce2d9edc6883914b9944928842964 1433 1432 2010-11-29T10:27:26Z Asa022 21 wikitext text/x-wiki XY-table, readout computer name - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED [[File:start_sketch.png]] Figure 1: Sketch of the XY-table === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. [[File:setup with text.PNG]] Figure 2: Picture of the XY-table set-up == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. [[File:fibremount2.png]] Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre above an ocular == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file [[File:Position Flash front panel.PNG]] Figure 4: Front panel of "position flash.vi" that calibrates and initialises the XY-table. Here the red flash point coincides with the flash at the upper left corner, and it is selected as origin. Notice that the axis of the image is parallel to the MPPC pixel array. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). [[File:Place Coords front panel.PNG]] Figure 5: Front panel of Place coords 50C MPPC.vi. The program recognises the upper left pixel and draws a cross at its center, while the flash point is located to the upper right side of the pixel. The outer red square is the search area. The program will only search for matching pixels inside the search area. == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. [[File:flowchart.png]] Figure 6: Flowchart of the DAQ == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. f945cae4970dac51b190ce3a3d16d1d4b37fe83a 1434 1433 2010-11-29T10:28:18Z Asa022 21 wikitext text/x-wiki XY-table, readout computer name - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED [[File:start_sketch.png]] Figure 1: Sketch of the XY-table === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. [[File:setup with text.PNG]] Figure 2: Picture of the XY-table set-up == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. [[File:fibremount2.png]] Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre above an ocular == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file [[File:Position Flash front panel.PNG]] Figure 4: Front panel of "position flash.vi" that calibrates and initialises the XY-table. Here the red flash point coincides with the flash at the upper left corner, and it is selected as origin. Notice that the axis of the image is parallel to the MPPC pixel array. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). [[File:Place Coords front panel.PNG]] Figure 5: Front panel of Place coords 50C MPPC.vi. The program recognises the upper left pixel and draws a cross at its center, while the flash point is located to the upper right side of the pixel. The outer red square is the search area. The program will only search for matching pixels inside the search area. == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. [[File:flowchart.png]] Figure 6: Flowchart of the DAQ == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. 672b7c638314986cd77079141aa56174d91ab048 1435 1434 2010-11-29T10:28:59Z Asa022 21 wikitext text/x-wiki XY-table, readout computer name - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED [[File:start_sketch.png]] Figure 1: Sketch of the XY-table === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. [[File:setup with text.PNG]] Figure 2: Picture of the XY-table set-up == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. [[File:fibremount2.png]] Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre above an ocular == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file [[File:Position Flash front panel.PNG]] Figure 4: Front panel of "position flash.vi" that calibrates and initialises the XY-table. Here the red flash point coincides with the flash at the upper left corner, and it is selected as origin. Notice that the axis of the image is parallel to the MPPC pixel array. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). [[File:Place Coords front panel.PNG]] Figure 5: Front panel of Place coords 50C MPPC.vi. The program recognises the upper left pixel and draws a cross at its center, while the flash point is located to the upper right side of the pixel. The outer red square is the search area. The program will only search for matching pixels inside the search area. == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program “apekatt” will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. [[File:flowchart.png]] Figure 6: Flowchart of the DAQ == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. 15771153a6f010b0b6725cbc2daa84e1dec841b6 1436 1435 2010-11-29T11:09:53Z Asa022 21 wikitext text/x-wiki XY-table, readout computer name - IFTSUB 041 090 == Introduction == The XY-table is designed to measure the response of single pixels in pixel based detectors. It focuses a narrow and fast LED light through a microscope in order to trigger a single pixel. While microstepper motors are used to position the detector. Since the steps of the motors are uneven, and the detectors have to be kept in the dark when triggered the coordinates of the pixels has to be mapped out and stored. The motor controller can then position the detector correctly when the light is off and the response of the pixels is being measured. Equipment: *Motor controller: SMC compact, uses Venus 1 command language. *Motor stages: X, Y and Z direction *Detector chuck: The table on top of the stages, uses vacuum to fix detectors to its surface. *Microscope: Olympus SZ-11 w/ SZ-CTV adapter for mounting cameras *Camera: Point Grey, flea2 (FL2G-13S2M/C), CCD camera. *Fibremount: Device that mounts a fibre above the left microscope ocular. *Fast LED pulser: Small analogue chip that pulses an attached LED [[File:start_sketch.png]] Figure 1: Sketch of the XY-table === HARDWARE === Figure 1 shows a principal sketch of how the XY-table is controlled and reads out data, while figure 2 shows a photo of the set-up. The set-up depicted in figure 2 is contained within a lightproof aluminium cabinet. The doors a held shut with bolts and has insulating rubber around to keep light out. The inside of the cabinet is also covered with black plastic so that any light entering will be absorbed. The cables going in and out of the cabinet goes through two s-shaped tubes that are filled with black cloth to keep light from entering. [[File:setup with text.PNG]] Figure 2: Picture of the XY-table set-up == Motor stages == The X and Y motor stages consist of a rail with a carriage on top where the carriage can go back and forth along the rail. In the middle of the rail there is screw bolt that moves the carriage when rotated. The screw bolt is driven by a stepper motor. The uneven steps in the motor stages might be corrected by tighten or loosing some screws fixing the carriage to the rail. The Y-stage is positioned at the bottom, while the X-stage is placed on top of the Y-stage carriage, and the Z-stage is placed atop the X-stage carriage. == Detector chuck == The detector chuck is placed on top of the Z-stage. It is a square aluminium table with a 2 x 4 cm2 area of small holes (3x5 holes). The holes are connected and have a common gas input at the back of the detector chuck. When vacuum or low pressure is applied to the gas input a detector covering the holes on top of the detector chuck will get stuck due to under pressure. This is an effective way of holding the detector fixed onto the motor stages while they move. There is a small vacuum pump outside the cabinet supplying vacuum to a set of valves inside the cabinet through a hose. == Motor controller == The motor controller’s purpose is to manage the motor stages. The motor controller is a SMC Compact, created by Micos. The controller has one RS-232 and one GPIB (IEEE-488) port for communication with a computer, though the GPIB seems to have malfunctioned. Neither Lars G. Johansen nor Andreas T. Samnøy has made the GPIB port work in their master thesises in 1999 and 2010 respectively. The controller also has a joystick for moving the motor stages. In order to control the stages via a computer a string of ASCII commands is sent to the controller. Each of the ASCII commands is separated by a space. The motor controller has its own coordinate system of where the stages are positioned, which can be sent to the computer by request. == Microscope with camera == The microscope is has two oculars and one camera slot. At the right backside of the microscope there is a small handle where one can choose whether the right ocular or the camera slot will be open. The left ocular is always open. There is an extra objective/lens attached to the microscope giving it a higher magnification which can easily be removed by unscrewing it. There is a ring of 12V LEDs connected to the objective which is used for illuminating (unsure of max current or power). The LEDs are connected to the blue and red cables coming out of the s-shaped tubes, which normally are connected to a power supply. The camera is a 1288x964 CCD camera with a 1/3 inch CCD chip where each of the pixels are 3.75 x 3.75 μm2. The camera is connected to the microscope by an adapter (Olympus SZ-CTV) that can fix any C-mount camera to the microscope. The camera is connected to the computer through a FireWire 800 (IEEE 1394b) cable. == Fibremount == In order to get a narrow and focused light spot through the microscope a small light source has to be fixed at the correct height above one of the oculars. At the correct height above the ocular the light will be perfectly focused through the microscope and onto any detector lying beneath. Furthermore, the smaller the light source is the more narrow the focused light will be onto the detector underneath the microscope. In order to get a narrow enough light source to shine into one of the oculars a LED is connected to one end of a fibre while the second end shines into a microscope ocular. At the left microscope ocular, which is always open, there is a device called the fibremount that fixes a normal multi-channel fibre with a ST-connector directly above the ocular. The fibremount is shown in figure 3. The ocular is inserted into the wide opening of the House and can be fastened by two screws. The ocular seems to be more stabile if one places a few rounds of electrical tape around the ocular and then simply presses the ocular into the House. The Rod with a connected fibre is placed inside the narrow opening of the House, and fastened by two screws. This way the user can select how far above the ocular the fibre ending should be. The height should be set such that light shining through the microscope should be as focused as possible. [[File:fibremount2.png]] Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre above an ocular == Fast LED pulser == In order to send very short light pulses the LED is connected to a fast LED pulser. The fast LED pulser is a small chip which is connected to a power supply and a signal generator through two lemo wires. The signal generator should be set to send a step signal as the fast LED pulser will then trigger the attached LED on its falling edge. The amount of light emitted depends on the voltage supplied by the power supply, and should be between 12-20V. Any sort of LED should work, preferably a high power led (> 1000 mcd) with a small emitting angle. == Calibrating LED light == In order to calibrate the light from the LED that shines through the microscope the LED should be connected to a DC source. This way the LED light that shines into the fibre can either be seen through the right ocular or on screen through the camera. The user of the system can then elevate or lower the rod inside the fibremount house to get a good focus of the light. The user can also see where the light will hit for position calibration. === SOFTWARE === The software for the XY-table is developed using LabVIEW, and is specifically designed for testing the Hamamatsu MultiPixel Photon Counter (MPPC). The MPPC is a 2 dimensional array of pixels, where each pixel works as a Geiger mode Avalanche PhotoDiode (APD). In other words, each of the pixel will sett of an identical charge signal when struck by a photon. The programs shown here are programs to test all the pixels on a MPPC. A program for the Zecotec MAPD (briefly tested) are also presented at the end. == MPPC programs == There are three MPPC programs, one that calibrates and initialise the XY table. A second program utilizes image recognition to find the motor controller coordinates when the LED light hits the centre of all the pixels and stores them on file. The last program uses the coordinates stored to find all the pixels and trigger them using the fast pulser. Before running the programs or at the very beginning of the first program described below the camera on the microscope should be turned such that the axis of the image given by the camera is parallel to the axis of the MPPC chip. This will make the image recognition process more efficient. == Calibration and initialisation, “Position flash.vi” == When running this program the LED should be powered by a DC power supply and the MPPC chip should be fixed to the detector chuck. It can then clearly be seen where the LED light hit the MPPC surface. The Z-stage which elevates and lowers the detector is used to focus both the image received by the camera and the LED light shining through the microscope. The front panel of the program is shown in figure 4. The user of the program should position the MPPC such that the LED light is focused and hits the centre of the upper left pixel. This position should be selected as origin. The flash point which is a camera pixel coordinate should be selected to coincide with the centre of the LED light when focused. This point tells the software where the LED light hits the MPPC when in focus and is marked with a red pixel on screen. The user then positions the LED light at the centre of the upper right pixel and focuses it such that the flash point and the LED light coincides again without changing the flash point coordinates; by just regulating the z-stage. The user then presses the button to calculate the x-base. Similarly the y-base is found by targeting the lower left pixel. The program now has two vectors running along the axis of the MPPC. These two vectors span out a two dimensional coordinate system whose axis is orthogonal with the axis of the MPPC chip. When the program is stopped the x- and y- bases along with the flash point are written to file [[File:Position Flash front panel.PNG]] Figure 4: Front panel of "position flash.vi" that calibrates and initialises the XY-table. Here the red flash point coincides with the flash at the upper left corner, and it is selected as origin. Notice that the axis of the image is parallel to the MPPC pixel array. == Mapping coordinates, “Place coords.vi” == There are two of these programs, one for the 025c MPPC and one for the 050c. When the program starts it imports the x- and y- bases, and the flash point that represent where the LED light will hit. An image of the Place cords.vi (050c version) is shown in figure 5. While the program runs the LED light should be turned off since it will disturb the image recognition sequence. The flash point points at the upper left pixel when the program start since this is selected as origin. In order to make the program recognise a pixel the user has to draw a frame around a single pixel in the image given by the camera and select the “Lear Pattern” button. To make a frame the square icon directly to the left of the image given by the camera has to be pressed. In order to be sure that the program recognises the pixel closest to the flash point a second frame should be drawn. The frame should be almost the size of two pixels, but should not be able to contain two pixels at once. The second frame is to be centred at the flash point. The user then presses the “Set Search area”. When both the frames have been drawn as depicted in figure 5 the “start coord finder” can be pressed. The program will then move the MPPC such that the centre of the recognised pixel moves towards the flashpoint. The movement is done by a simple proportional controller algorithm. The number of times it will be moved is given in the “Control loops” and is normally 5. The distance it moves per step is proportional to the “Prop Const” which is a negative number (if the number is positive it will move away from flash point). After all the control loops have been executed the flash point and the centre of the pixel should be on top of each other. The program then writes the motor controllers coordinate to file and moves over to the neighbouring pixel where the sequence repeats itself. This way the program finds all the pixel’s coordinates and writes them to file. In the case of the 25C MPPC the pixels of different rows have different shapes. All the odd number rows have one shape which is different from the even number rows. The program then demands that the user frames a pixel from an odd row (switch in P1 position) and presses learn pattern, then does the same for an even row pixel (P2). [[File:Place Coords front panel.PNG]] Figure 5: Front panel of Place coords 50C MPPC.vi. The program recognises the upper left pixel and draws a cross at its center, while the flash point is located to the upper right side of the pixel. The outer red square is the search area. The program will only search for matching pixels inside the search area. == Check coordinates == After the coordinates for all the pixels have been written to file the coordinates should be checked. The LED should now be powered by a power supply and the program "check coords.vi" will move the XY-table to all the stored coordinates. This way the user can see if the LED light hits the pixels correctly or if a new set of coordinates should be found. If there is an error where the light always hits one side of the pixel this can be corrected for in the measurement program. == Measure pixels == This is the program which measures the response of each pixel. The LED should now be connected to the fast pulser. The fast pulser will continuously pulse the LED at a rate set by the signal generator and is not controlled by the computer. The program reads out the response from the MPPC whenever the LED is pulsed and the ADC is ready. The Data Acquisition (DAQ) will be further elaborated below. The number of measurements done on each pixel is set by the user, the default is 10,000 measurements. The user also has to select what kind of MPPC is being measured, 25c or 50c. The program writes a .txt file for each pixel containing all the measurements from it. The files have a header and two columns, the left column is the voltage amplitude of the signal and the left column is the charge given by MPPC. The charge is measured in ADC channel numbers which is proportional to the actual charge in coulomb. == Data Acquisition System (DAQ) == The DAQ described here is created for measuring the MPPC and the MAPD detector. It gives good results for the MPPC, but the signal from the MAPD drowns in noise from the XY-table and the unshielded fast pulser. Little time has been used to make the MAPD work with the XY-table so far. The signal generator is set at approximately 2000 kHz step function with a 5 ns rise and fall time. The signal is sent into a fan out which splits the signal and sends two identical signals to both the external trigger on the ADC and the fast pulser. The fast pulser emits light on the falling edge of the step function delivered by the signal generator. The amount of light depends on the voltage supplied to it as explained in the hardware section. The MPPC is connected to a read out circuit inside a box (read out box) which is fixed to the detector chuck. The MPPC receives its bias voltage from a high voltage power supply through the read out circuit. The charge emitted from the MPPC goes through a resistance in the circuit which produces a voltage signal. The voltage signal goes into a preamplifier (100 gain) before it is sent to the ADC. The ADC digitizes any incoming signal whenever it receives a signal at the external trigger and is not busy. [[File:flowchart.png]] Figure 6: Flowchart of the DAQ == MAPD == One program for the MAPD has been built, but since there signal to noise ratio is so low it has never been used. If the noise is somehow reduced the program should be usable. Since the MAPD has a smooth surface image recognition cannot be implemented. Furthermore the pixel density of the MAPD is so high that with the current system the LED pulse will probably strike several pixels. This does not mean that the XY-table with reduced noise is useless in characterising the MAPDs. If the XY-table noise is reduced one could still find out whether or not some areas of the MAPD yields more or less gain then the rest. The program uses the same LED system for triggering and the same DAQ as described above for the MPPC. The program is split into two parts; the first is similar to the initialisation and calibration program for the MPPC, while the second does the data acquisition. In the first part the user selects a squared area where the measurements are to take place. The LED light should now be powered by the power supply in order to see where it hits the MAPD surface. To select this squared measurement area the user moves the MAPD such that the LED light hits one of the corners of the wanted area, and focuses it with the z-stage. This position is selected as origin. The MAPD is then to be positioned and focused at one of the neighbouring corners and be selected as either X- or Y-base. Before selecting it as a base the number of steps in this direction should be entered in “Steps”. The same way the other neighbouring corner of the origin corner is selected as the other base. The two bases now works as two vectors that spans out a square. This way a user can select a square where the program measures the MAPD 3 times along one direction and 10 times along the other by selecting 3 and 10 steps in their respective bases. When both of the bases have been set the light has to be shut off and the LED connected to the fast pulser. The button “start scan” will then commence the measurement of the MAPD. 30acffb4c4a9586c30557dd69213839d1ef6af11 6 319 1421 2010-11-29T09:42:39Z Asa022 21 Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre with a ST-connector above an ocular wikitext text/x-wiki Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre with a ST-connector above an ocular 83e21a216e0cfde7e83be6efd60e0634b61109e9 6 320 1422 2010-11-29T09:43:40Z Asa022 21 Figure 6: Flowchart of the DAQ wikitext text/x-wiki Figure 6: Flowchart of the DAQ 547c0c778db1542ebac45f181af9e333ff7c4817 6 321 1423 2010-11-29T09:44:45Z Asa022 21 Figure 5: Front panel of Place coords 50C MPPC.vi. The program recognises the upper left pixel and draws a cross at its center, while the flash point is located to the upper right side of the pixel. The outer red square is the search area. The program will only search for matching pixels inside the search area. wikitext text/x-wiki Figure 5: Front panel of Place coords 50C MPPC.vi. The program recognises the upper left pixel and draws a cross at its center, while the flash point is located to the upper right side of the pixel. The outer red square is the search area. The program will only search for matching pixels inside the search area. 1f1e1f55661601b056dbe0d3279659c07eb8e9d2 6 322 1424 2010-11-29T09:45:29Z Asa022 21 Figure 4: Front panel of "position flash.vi" that calibrates and initialises the XY-table. Here the red flash point coincides with the flash at the upper left corner, and it is selected as origin. Notice that the axis of the image is parallel to the MPPC pixel array. wikitext text/x-wiki Figure 4: Front panel of "position flash.vi" that calibrates and initialises the XY-table. Here the red flash point coincides with the flash at the upper left corner, and it is selected as origin. Notice that the axis of the image is parallel to the MPPC pixel array. bb322fa9977d6758ba8a36ed2306998bca1b7e07 6 323 1425 2010-11-29T09:47:28Z Asa022 21 Figure 2: Picture of the XY-table set-up wikitext text/x-wiki Figure 2: Picture of the XY-table set-up e8be9808d7e5a6a0ca93b983268237db87d3563a 6 324 1426 2010-11-29T09:48:13Z Asa022 21 Figure 1: Sketch of the XY-table wikitext text/x-wiki Figure 1: Sketch of the XY-table 0760af9b9df4e2104ab3daa2f0b227c5f590c211 6 325 1429 2010-11-29T10:20:29Z Asa022 21 Figure 1: Sketch of the XY-table wikitext text/x-wiki Figure 1: Sketch of the XY-table 0760af9b9df4e2104ab3daa2f0b227c5f590c211 6 326 1430 2010-11-29T10:20:55Z Asa022 21 Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre above an ocular wikitext text/x-wiki Figure 3: Sketch and picture of the fibremount that holds a multi-channel fibre above an ocular 2d8d9036a78a753f1842bb2ac3acb04b104474c7 6 327 1431 2010-11-29T10:22:05Z Asa022 21 Figure 6: Flowchart of the DAQ wikitext text/x-wiki Figure 6: Flowchart of the DAQ 547c0c778db1542ebac45f181af9e333ff7c4817 0 203 1437 1294 2010-12-03T15:54:15Z Dfe002 7 /* Documents to bring */ added health insurance note wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". There is a CERN shuttle bus to/from the airport ([https://espace.cern.ch/info-RegularShuttleService/default.aspx timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. [[User:Dfe002|Dominik]] 15:56, 22 March 2010 (UTC) 7c4b918468d33f8913264ea9457d0b871698fad2 1438 1437 2010-12-03T16:00:13Z Dfe002 7 ãdded printer section wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. The current situation is: Bus 56 now runs CERN-Meyrin Village. Change to tram 14/16 at the stop "Vaudagne" (the tram continues one stop to "Graviere"). To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. A new line 57 also runs through the ZIMEYSA area, and connects to bus 56 at the stop "P+R Planche" (just downhill from CERN). The bus 28 no longer runs to Meyrin, but continues to the Vernier area. You may take this bus (or bus 23, following the same path), and change to tram 14 or 16 at the stop "Blandonnet", then change to bus 56 at "Vaudagne". You may of course till take bus 10, change to tram 14 or 16 at "Bouchet", then change to bus 56 at "Vaudagne". There is a CERN shuttle bus to/from the airport ([https://espace.cern.ch/info-RegularShuttleService/default.aspx timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 80680186f7af2063121b3755a4785ba3c12ff6d5 0 328 1440 2011-01-03T11:04:54Z Bwa021 51 initial analysis page setup wikitext text/x-wiki = Local Analysis Help = The goal of this page is to collect experiences with data analysis in general with a focus on the Grid and AAF. It should lead to a template that can be used by the whole Bergen group. It should make it easier to start and with a common starting point, help should be easier to find. It also can be a place to find out who is doing what. As a suggestion of pages to come * [[People]] - short description who is doing what. Maybe link to code with explanations * [[Physics Working Groups]] - important people - meeting summaries - explaining used methods * [[Template]] - code template with documentation * [[Examples]] collection of user analysises, with histogram pictures, talks where they were used * [[Further reading]] * [[AliEn news]] - summary of the offline weeks * [[AliRoot installation]] * [[Acronyms index]] e54541004f4e39ab808d426309d7fb6afb206933 1441 1440 2011-01-03T11:05:15Z Bwa021 51 wikitext text/x-wiki The goal of this page is to collect experiences with data analysis in general with a focus on the Grid and AAF. It should lead to a template that can be used by the whole Bergen group. It should make it easier to start and with a common starting point, help should be easier to find. It also can be a place to find out who is doing what. As a suggestion of pages to come * [[People]] - short description who is doing what. Maybe link to code with explanations * [[Physics Working Groups]] - important people - meeting summaries - explaining used methods * [[Template]] - code template with documentation * [[Examples]] collection of user analysises, with histogram pictures, talks where they were used * [[Further reading]] * [[AliEn news]] - summary of the offline weeks * [[AliRoot installation]] * [[Acronyms index]] 73d847105d3352a484ece4983717c1f31627a1b0 0 309 1443 1349 2011-01-05T09:51:59Z Dfe002 7 added new files wikitext text/x-wiki == Goal == The aim of this phys117 course is to build a small array with 9 crystals coupled to silicon photo multipliers. For this we need to design the circuit to read out the MPPCs and include a pre amplifier there. We also need to have a light tight containment that holds the crystals and couples them to the MPPCs. To measure the physical crosstalk the crystals have to be individually wrapped. The readout of the whole system is then done in Labview through two 14 bit 2 Ghz oversampling CAEN ADCs. The hardware has been built in autumn 2010, and the next task is to perform a the measurements: energy resolution, linearity and event topology. == Resources == [http://web.ift.uib.no/~dominik/files/phys117/PHYS117%20-%20PET%20scanner.pdf Project report of phys117 fall 2010]<br> [http://web.ift.uib.no/~dominik/files/phys117/MPPC%20Amplifier%209%20routed2.brd Eagle board layout of 3x3 matrix]<br> [http://web.ift.uib.no/~dominik/files/phys117/MPPC%20Amplifier%209%20routed2.sch Eagle schematics file of 3x3 layout]<br> [http://web.ift.uib.no/~dominik/files/phys117/MPPC%20Amplifier.zip Eagle schematics and layout]<br> [http://web.ift.uib.no/~dominik/files/phys117/Multisim.zip Multisim simulation model]<br> [http://www.farnell.com/datasheets/92509.pdf AD8000YDZ preamp datasheet]<br> 1124ed3abd94c4105482f30a8be574d3387232f8 0 222 1444 1275 2011-01-10T13:48:31Z Gge002 52 added tips&tricks wikitext text/x-wiki == ASIM - Atmosphere Space Interaction Monitor == ASIM is an experiment for the International Space Station (ISS) external facilities on the Columbus module. ASIM is aimed at the study of high-altitude optical emissions from the stratosphere and mesosphere, the Transient Luminous Events (TLEs: Red Sprites, Blue Jets, Elves) and the Terrestrial Gamma Flashes (TGFs) (Neubert et al., 2006). ASIM has been through a Phase-A (Development and Design, 2004-2005) and a Phase-B (Breadboard and Feasibility, 2007-2009) study. In May 2009 the Program Board for Human Spaceflight and Exploration (PB-HME) decided that the ASIM payload shall be part of the ELIPS-3 program and allocated funding to ASIM from the program. A flight model of the ASIM payload will be built through Phase C/D starting early 2010. ---- [[ASIM-BGO]] [[ASIM-CZT]] [[Tips 'n' Tricks]] [[Category:Space physics]] 8b19f077c25eaee5b36d9dc2d965205695a0a26d 1446 1444 2011-01-10T14:09:00Z Gge002 52 wikitext text/x-wiki == ASIM - Atmosphere Space Interaction Monitor == ASIM is an experiment for the International Space Station (ISS) external facilities on the Columbus module. ASIM is aimed at the study of high-altitude optical emissions from the stratosphere and mesosphere, the Transient Luminous Events (TLEs: Red Sprites, Blue Jets, Elves) and the Terrestrial Gamma Flashes (TGFs) (Neubert et al., 2006). ASIM has been through a Phase-A (Development and Design, 2004-2005) and a Phase-B (Breadboard and Feasibility, 2007-2009) study. In May 2009 the Program Board for Human Spaceflight and Exploration (PB-HME) decided that the ASIM payload shall be part of the ELIPS-3 program and allocated funding to ASIM from the program. A flight model of the ASIM payload will be built through Phase C/D starting early 2010. ---- [[ASIM-BGO]] [[ASIM-CZT]] [[Tips 'n' Tricks (Programming)]] [[Category:Space physics]] ab0a61a4548f6feae44bd4cbfa6c4f4e11995ef6 1447 1446 2011-01-10T14:09:24Z Gge002 52 Undo revision 1446 by [[Special:Contributions/Gge002|Gge002]] ([[User talk:Gge002|Talk]]) wikitext text/x-wiki == ASIM - Atmosphere Space Interaction Monitor == ASIM is an experiment for the International Space Station (ISS) external facilities on the Columbus module. ASIM is aimed at the study of high-altitude optical emissions from the stratosphere and mesosphere, the Transient Luminous Events (TLEs: Red Sprites, Blue Jets, Elves) and the Terrestrial Gamma Flashes (TGFs) (Neubert et al., 2006). ASIM has been through a Phase-A (Development and Design, 2004-2005) and a Phase-B (Breadboard and Feasibility, 2007-2009) study. In May 2009 the Program Board for Human Spaceflight and Exploration (PB-HME) decided that the ASIM payload shall be part of the ELIPS-3 program and allocated funding to ASIM from the program. A flight model of the ASIM payload will be built through Phase C/D starting early 2010. ---- [[ASIM-BGO]] [[ASIM-CZT]] [[Tips 'n' Tricks]] [[Category:Space physics]] 8b19f077c25eaee5b36d9dc2d965205695a0a26d 0 329 1445 2011-01-10T14:07:33Z Gge002 52 Created the page wikitext text/x-wiki ==Programming T&T== #C/C++ #*[[ANSI C]] T&T #*[[ISO/IEC C++]] (Unmanaged C++) T&T #*[[C++/CLI]] (Managed C++) T&T #Matlab T&T #LabVIEW T&T [[Category:Programming]] [[Category:Tips and Tricks]] fe6ee485555353ac537d5c40b3076fa0d35b6228 1448 1445 2011-01-10T14:13:05Z Gge002 52 MEX wikitext text/x-wiki ==Programming T&T== #C/C++ #*[[ANSI C]] T&T #*[[ISO/IEC C++]] (Unmanaged C++) T&T #*[[C++/CLI]] (Managed C++) T&T #Matlab T&T #*[[Using MEX-Files to Call C/C++ and Fortran Programs]] #LabVIEW T&T [[Category:Programming]] [[Category:Tips and Tricks]] 30bbdaf3ee7cf92c20cf82d808b6bba8ca9a9f0e 0 330 1449 2011-01-10T15:14:36Z Gge002 52 Created the page, waiting for an add-on that can display source code wikitext text/x-wiki ==Understanding MEX== MEX-files (MATLAB executables) are used to call large pre-existing C/C++ and Fortran programs from MATLAB without translating them into MATLAB. Another advantage is that C/C++ code is generally faster than MATLAB. The best source of information is MathWorks' knowledge database. To understand C/C++ Source MEX-Files see: :*[http://www.mathworks.com/help/techdoc/matlab_external/f43721.html|C/C++ Source MEX-Files] (last checked 10 Jan 2011) To understand how to use MEX-Files to Call C/C++ and Fortran Programs see :*[http://www.mathworks.com/help/techdoc/matlab_external/f29502.html|Using MEX-Files to Call C/C++ and Fortran Programs] ==Tips 'n' Tricks== #'''Where to place the gateway routine within the C/C++ program''' - it looks like the gateway routine should be the last routine in the code. This sheds the problem with undefined variables and alike. I (GG) haven't found any place in the knowledge base where this is mentioned. Maybe it is not true in all cases either. Here follows an example that is a modification of the original MATLAB code from the knowledge database (see link "MEX-Files to Call C/C++ and Fortran Programs" above). In the case below three input parameters are required, while in the original code only two are necessary. A comparison between the two version helps to find the in-s and out-s. [[Category:Programming]] [[Category:Tips and Tricks]] [[Category:MATLAB]] b7a32e3a11ddd88ef0243421f740c144ee31007c 1450 1449 2011-01-14T08:52:56Z Gge002 52 added the code wikitext text/x-wiki ==Understanding MEX== MEX-files (MATLAB executables) are used to call large pre-existing C/C++ and Fortran programs from MATLAB without translating them into MATLAB. Another advantage is that C/C++ code is generally faster than MATLAB. The best source of information is MathWorks' knowledge database. To understand C/C++ Source MEX-Files see: :*[http://www.mathworks.com/help/techdoc/matlab_external/f43721.html|C/C++ Source MEX-Files] (last checked 10 Jan 2011) To understand how to use MEX-Files to Call C/C++ and Fortran Programs see :*[http://www.mathworks.com/help/techdoc/matlab_external/f29502.html|Using MEX-Files to Call C/C++ and Fortran Programs] ==Tips 'n' Tricks== #'''Where to place the gateway routine within the C/C++ program''' - it looks like the gateway routine should be the last routine in the code. This sheds the problem with undefined variables and alike. I (GG) haven't found any place in the knowledge base where this is mentioned. Maybe it is not true in all cases either. Here follows an example that is a modification of the original MATLAB code from the knowledge database (see link "MEX-Files to Call C/C++ and Fortran Programs" above). In the case below three input parameters are required, while in the original code only two are necessary. A comparison between the two version helps to find the in-s and out-s. <source lang="cpp"> #include "mex.h" #include "matrix.h" /* * arrayProduct.c * Multiplies an input scalar times a 1xN matrix * and outputs a 1xN matrix * * This is a modified version of the MEX-file from MathWorks' knowledge database. * http://www.mathworks.com/help/techdoc/matlab_external/f29502.html * * The modifications are (LINE REFERENCES DIFFERENT FROM ORIGINAL): * the original "double multiplier" is replaced with "double multiplier1" (line 61) * introduced "double multiplier2" (line 62) * line 37 - added "double w" * line 42 - added " * w " * line 73 - changed message to be displayed * line 98, 99 - added those lines * line 113 - added "multiplier2" and changed "multiplier" with "multiplier1" */ /**************************************************/ /**************************************************/ /************* SOME ROUTINE *************/ /**************************************************/ /**************************************************/ /* Multiplies an input scalar times a 1xN matrix */ /* and output is a 1xN matrix */ /**************************************************/ /**************************************************/ void arrayProduct(double x, double *y, double *z, double w, mwSize n) { mwSize i; for (i=0; i<n; i++) { z[i] = x * y[i] * w; } } /**********************************************************/ /**********************************************************/ /************* THE GATEWAY FUNCTION *************/ /**********************************************************/ /**********************************************************/ void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) { /*** Variable declarations ***/ double multiplier1; // input scalar double multiplier2; // input scalar double *inMatrix; // 1xN input matrix mwSize ncols; // size of matrix double *outMatrix; // output matrix /*** CODE ***/ // check for proper number of arguments if(nrhs!=3) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nrhs", "Three inputs required."); } if(nlhs!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nlhs", "One output required."); } // make sure the first input argument is scalar if( !mxIsDouble(prhs[0]) || mxIsComplex(prhs[0]) || mxGetNumberOfElements(prhs[0])!=1 ) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notScalar", "Input multiplier must be a scalar."); } // check that number of rows in second input argument is 1 if(mxGetM(prhs[1])!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notRowVector", "Input must be a row vector."); } // get the value of the first scalar input multiplier1 = mxGetScalar(prhs[0]); // get the value of the second scalar input multiplier2 = mxGetScalar(prhs[2]); // create a pointer to the real data in the input matrix inMatrix = mxGetPr(prhs[1]); // get dimensions of the input matrix ncols = mxGetN(prhs[1]); // create the output matrix */ plhs[0] = mxCreateDoubleMatrix(1,ncols,mxREAL); // get a pointer to the real data in the output matrix outMatrix = mxGetPr(plhs[0]); // call the computational routine arrayProduct(multiplier1,inMatrix,outMatrix,multiplier2,ncols); } </source> [[Category:Programming]] [[Category:Tips and Tricks]] [[Category:MATLAB]] 33a2b88f6006c2ad6df8afb2a9a67a64c7497847 1451 1450 2011-01-14T15:18:28Z Gge002 52 fixed broken links, some new text & formating wikitext text/x-wiki ==Understanding MEX== MEX-files (MATLAB executables) are used to call large pre-existing C/C++ and Fortran programs from MATLAB without translating them into MATLAB. Another advantage is that C/C++ code is generally faster than MATLAB. The best source of information is MathWorks' knowledge database. To understand C/C++ Source MEX-Files see: :*[http://www.mathworks.com/help/techdoc/matlab_external/f43721.html C/C++ Source MEX-Files] (last checked 10 Jan 2011) To understand how to use MEX-Files to Call C/C++ and Fortran Programs see :*[http://www.mathworks.com/help/techdoc/matlab_external/f29502.html Using MEX-Files to Call C/C++ and Fortran Programs] (last checked 10 Jan 2011) ==Tips 'n' Tricks== #'''Where to place the gateway routine within the C/C++ program''' #*''The whole code can be placed in the Gateway routine'' #*''At the end'' - it looks like the gateway routine should be the last routine in the code if more routines are present. This sheds the problem with undefined variables and alike. I (GG) haven't found any place in the knowledge base where this is mentioned. Maybe it is not true in all cases either. Here follows an example that is a modification of the original MATLAB code from the knowledge database (see link "MEX-Files to Call C/C++ and Fortran Programs" above). In the case below three input parameters are required, while in the original code only two are necessary. A comparison between the two version helps to find the in-s and out-s. <source lang="cpp"> #include "mex.h" #include "matrix.h" /* * arrayProduct.c * Multiplies an input scalar times a 1xN matrix * and outputs a 1xN matrix * * This is a modified version of the MEX-file from MathWorks' knowledge database. * http://www.mathworks.com/help/techdoc/matlab_external/f29502.html * * The modifications are (LINE REFERENCES DIFFERENT FROM ORIGINAL): * the original "double multiplier" is replaced with "double multiplier1" (line 61) * introduced "double multiplier2" (line 62) * line 37 - added "double w" * line 42 - added " * w " * line 73 - changed message to be displayed * line 98, 99 - added those lines * line 113 - added "multiplier2" and changed "multiplier" with "multiplier1" */ /**************************************************/ /**************************************************/ /************* SOME ROUTINE *************/ /**************************************************/ /**************************************************/ /* Multiplies an input scalar times a 1xN matrix */ /* and output is a 1xN matrix */ /**************************************************/ /**************************************************/ void arrayProduct(double x, double *y, double *z, double w, mwSize n) { mwSize i; for (i=0; i<n; i++) { z[i] = x * y[i] * w; } } /**********************************************************/ /**********************************************************/ /************* THE GATEWAY FUNCTION *************/ /**********************************************************/ /**********************************************************/ void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) { /*** Variable declarations ***/ double multiplier1; // input scalar double multiplier2; // input scalar double *inMatrix; // 1xN input matrix mwSize ncols; // size of matrix double *outMatrix; // output matrix /*** CODE ***/ // check for proper number of arguments if(nrhs!=3) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nrhs", "Three inputs required."); } if(nlhs!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nlhs", "One output required."); } // make sure the first input argument is scalar if( !mxIsDouble(prhs[0]) || mxIsComplex(prhs[0]) || mxGetNumberOfElements(prhs[0])!=1 ) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notScalar", "Input multiplier must be a scalar."); } // check that number of rows in second input argument is 1 if(mxGetM(prhs[1])!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notRowVector", "Input must be a row vector."); } // get the value of the first scalar input multiplier1 = mxGetScalar(prhs[0]); // get the value of the second scalar input multiplier2 = mxGetScalar(prhs[2]); // create a pointer to the real data in the input matrix inMatrix = mxGetPr(prhs[1]); // get dimensions of the input matrix ncols = mxGetN(prhs[1]); // create the output matrix */ plhs[0] = mxCreateDoubleMatrix(1,ncols,mxREAL); // get a pointer to the real data in the output matrix outMatrix = mxGetPr(plhs[0]); // call the computational routine arrayProduct(multiplier1,inMatrix,outMatrix,multiplier2,ncols); } </source> [[Category:Programming]] [[Category:Tips and Tricks]] [[Category:MATLAB]] a1ecf2eda14b1b67d7e193d035cb3ee7461a80c2 0 21 1452 1395 2011-01-17T10:13:38Z Dfe002 7 updated student list wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Oliver * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 30.10. - 08.10.10: IEEE 2010 Nuclear Science Symposium and Medical Imaging Conference(http://www.nss-mic.org/2010/) == For internal use == [[material]] that can be used in official presentations. 9ea88302dba4449b7c0ffc83233a717a162a471e 0 23 1453 353 2011-01-17T13:30:48Z Dfe002 7 wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, ... == Documentation == [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3D report 06-03-09.pdf 3D Report Cedric Virmontois] ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] 39e9eb7642e4e334c45f343e811c4c40584d19a6 1454 1453 2011-01-17T13:31:46Z Dfe002 7 /* Documentation */ wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, ... == Documentation == [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3D%20report%20 06-03-09.pdf 3D Report Cedric Virmontois] ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] 746497c3e4389782ba3909714266d9d14fe2d1dc 1455 1454 2011-01-17T13:32:10Z Dfe002 7 /* Documentation */ wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, ... == Documentation == [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3D%20report%2006-03-09.pdf 3D Report Cedric Virmontois] ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] 5741ced52fffebe69e93826200bb5e5f57aa2a48 1456 1455 2011-01-17T13:33:22Z Dfe002 7 /* Documentation */ wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, ... == Documentation == [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3d/3D%20report%2006-03-09.pdf 3D Report Cedric Virmontois] ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] 1597b018f0670d7b92a62003c997682c68b199ee 0 1 1457 751 2011-01-18T10:13:42Z Hsa061 18 wikitext text/x-wiki <big>'''Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] * [[DAMARA]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] deeacdb2690c3ffb09f7de2dcee55ad1589c6950 0 331 1458 2011-01-18T10:14:44Z Hsa061 18 Created page with ' * [[How to get to Bergen]]' wikitext text/x-wiki * [[How to get to Bergen]] 8a08052ce7843cf3046e50fd54557c15088e3e86 1459 1458 2011-01-18T10:15:23Z Hsa061 18 wikitext text/x-wiki * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN as a new student]] 31d269693d774afb1c89e99e36eb275eb9f114ae 0 332 1460 2011-01-18T10:21:53Z Hsa061 18 Created page with 'First make sure that you have accomodation, bank account and visa if needed. Then arriving at the IFT these are the things to do: - Contact your supervisor or other contact pe…' wikitext text/x-wiki First make sure that you have accomodation, bank account and visa if needed. Then arriving at the IFT these are the things to do: - Contact your supervisor or other contact person, he/she will introduce you to the relevant people at the IFT - Talk to Elin Bjerkan to get done the administrative part - Get access card to the IFT building - Get an office and keys from Gjert Furhovden - Get internet connection and accounts from Magne Håvåg - Get access to the Twiki - Make sure you have a computer and set this up accordingly (if you are a Master student or visitor student you will use one of the PCs in the room allocated) - If you are taking courses talk to Terje Finnekås - If you work in the detector laboratory read through the safety rules and detector lab manual and talk to Dominik Fehlker about using the laboratory 22cc4a5d80965214cc0119cc4069f77715e59d61 0 332 1461 1460 2011-01-18T10:22:32Z Hsa061 18 wikitext text/x-wiki First make sure that you have accomodation, bank account and visa if needed. Then arriving at the IFT these are the things to do: - Contact your supervisor or other contact person, he/she will introduce you to the relevant people at the IFT - Talk to Elin Bjerkan to get done the administrative part - Get access card to the IFT building - Get an office and keys from Gjert Furhovden - Get internet connection and accounts from Magne Håvåg - Get access to the Twiki - Make sure you have a computer and set this up accordingly (if you are a Master student or visitor student you will use one of the PCs in the room allocated) - If you are taking courses talk to Terje Finnekås - If you work in the detector laboratory read through the safety rules and detector lab manual and talk to Dominik Fehlker about using the laboratory 12b267a2aa5452982d1e4b236e98fb18b1ac0e3a 1462 1461 2011-01-18T10:24:10Z Hsa061 18 wikitext text/x-wiki First make sure that you have accomodation, bank account and visa if needed. Then arriving at the IFT these are the things to do: * Contact your supervisor or other contact person, he/she will introduce you to the relevant people at the IFT * Talk to Elin Bjerkan to get done the administrative part * Get access card to the IFT building * Get an office and keys from Gjert Furhovden * Get internet connection and accounts from Magne Håvåg * Get access to the Twiki * Make sure you have a computer and set this up accordingly (if you are a Master student or visitor student you will use one of the PCs in the room allocated) * If you are taking courses talk to Terje Finnekås * If you work in the detector laboratory read through the safety rules and detector lab manual and talk to Dominik Fehlker about using the laboratory 51561897f2ef2673711e950fd3ba359fd4cd8e02 1463 1462 2011-01-18T10:28:36Z Hsa061 18 wikitext text/x-wiki First make sure that you have accomodation, bank account and visa if needed. Then arriving at the IFT these are the things to do: * Contact your supervisor or other contact person, he/she will introduce you to the relevant people at the IFT * Talk to Elin Bjerkan to get done the administrative part * Get access card to the IFT building * Get an office and keys from Gjert Furhovden * Get internet connection and accounts from Magne Håvåg * Get access to the Twiki from Dominik Fehlker or Thomas Burgess * Make sure you have a computer and set this up accordingly (if you are a Master student or visitor student you will use one of the PCs in the room allocated) * If you are taking courses talk to Terje Finnekås * If you work in the detector laboratory read through the safety rules and detector lab manual and talk to Dominik Fehlker about using the laboratory b55402602d745b0a1ef91682888147a63b54fbba 1486 1463 2011-01-20T11:01:10Z Jli051 54 wikitext text/x-wiki First make sure that you have accomodation, bank account and visa if needed. Then arriving at the IFT these are the things to do: * Contact your supervisor or other contact person, he/she will introduce you to the relevant people at the IFT * Talk to Elin Bjerkan to get done the administrative part * Get access card to the IFT building. Go to the expedition office at the third floor where you have to fill out some forms which are then delivered at the card center just down the block from the ITF building. * Get an office and keys from Gjert Furhovden * Get internet connection and accounts by first talking to Magne Håvåg and then applying for an account at https://sebra.uib.no which then has to be approved. * Get access to the Twiki from Dominik Fehlker or Thomas Burgess. First you need to have the UiB account and then you need to log in to the twiki using your UiB username and password. This ads you to the userlist and allows the admins to enable your account. * Make sure you have a computer and set this up accordingly (if you are a Master student or visitor student you will use one of the PCs in the room allocated) * If you are taking courses talk to Terje Finnekås * If you work in the detector laboratory read through the safety rules and detector lab manual and talk to Dominik Fehlker about using the laboratory bc2536d2a4bed2b094be0b70f70f0a30366b393f 1489 1486 2011-01-24T10:27:26Z Hsa061 18 wikitext text/x-wiki First make sure that you have accomodation, bank account and visa if needed. Then arriving at the IFT these are the things to do: * Contact your supervisor or other contact person, he/she will introduce you to the relevant people at the IFT * Talk to Elin Bjerkan to get done the administrative part * Get access card to the IFT building. Go to the expedition office at the third floor where you have to fill out some forms which are then delivered at the card center just down the block from the ITF building. * Get an office and keys from Gjert Furhovden * Get internet connection and accounts by first talking to Magne Håvåg and then applying for an account at https://sebra.uib.no which then has to be approved. * Get access to the Twiki from Dominik Fehlker or Thomas Burgess. First you need to have the UiB account and then you need to log in to the twiki using your UiB username and password. This ads you to the userlist and allows the admins to enable your account. * Make sure you have a computer and set this up accordingly (if you are a Master student or visitor student you will use one of the PCs in the room allocated) * If you are taking courses talk to Terje Finnekås * If you work in the detector laboratory read through the safety rules and detector lab manual and talk to Dominik Fehlker about using the laboratory * Make sure you are on the relevant mailing lists and hypernews: ift-atlas, detectorlab, ... a6da7409c711963e8f2d3027fb696fc945781f11 0 331 1464 1459 2011-01-18T10:31:49Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN as a new student]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html == Computing == f9e83e3558b525a6445b293963049b8fb3ca0a6e 1465 1464 2011-01-18T10:33:26Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html == Computing == f5da904559032600b5a611c382352e7842c9f796 1467 1465 2011-01-18T10:57:08Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html == Computing == When you have an ATLAS account you can work yourway through this one: https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook 1cb16a480389f7f2a02209fb4c32c6681bc6ca19 1468 1467 2011-01-18T10:58:33Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html == Computing == When you have an ATLAS account you can work yourway through this link: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook e995ec3da920d7d4f3e785ab7564d4246785b895 1469 1468 2011-01-18T10:59:39Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html == Computing == When you have an ATLAS account you can work yourway through this link: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials 1d68f346d49af87906e844a2e2fa2824a39ea3cf 1470 1469 2011-01-18T11:01:07Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics == Computing == When you have an ATLAS account you can work yourway through this link: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials c7d2b7f9d6f8d0686253a608ef6e12a3449d86fb 1471 1470 2011-01-18T11:01:58Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics == Computing == When you have an ATLAS account you can work yourway through this link: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials adc38267e94533a4a9c4a99556dd82fd34f8617a 1475 1471 2011-01-18T11:08:06Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics == Computing == When you have an ATLAS account you can work your way through this link: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials dd931811a0a8643f54f68808c91f212f4865f0a4 1476 1475 2011-01-18T11:23:16Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials b51634449346f54785d530ada6d9c9a0fd2133f0 1490 1476 2011-02-07T08:01:53Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials 2a3d9f2f982b7f4701d14f7356cc8a35209f1236 1492 1490 2011-02-07T08:06:44Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Other stuff: * [[Useful Linux commands]] 719eebfc457259dc4c3e6f6e35a65cede3d51213 0 333 1466 2011-01-18T10:43:28Z Hsa061 18 Created page with ' FIrst follow these instructions, from Bergen you can already do point 3 on this list: * http://atlassec.web.cern.ch/atlassec/Registration.htm' wikitext text/x-wiki FIrst follow these instructions, from Bergen you can already do point 3 on this list: * http://atlassec.web.cern.ch/atlassec/Registration.htm 0b7ea76d02adfb55c19defde93d61ff7b32754c2 0 334 1472 2011-01-18T11:02:08Z Hsa061 18 Created page with ' https://tjinfo.uib.no/nettkonto' wikitext text/x-wiki https://tjinfo.uib.no/nettkonto 033f3f82875849bca71c3aa48b025a0926910240 1473 1472 2011-01-18T11:03:46Z Hsa061 18 wikitext text/x-wiki * Information about how to come to Bergen and accomodation can be found on this link: http://www.uib.no/People/hsa061/DAMARA/Contact_Information.html * You can get a visitors account from your contact person fill in the form on https://tjinfo.uib.no/nettkonto 30360131f037a5f03b588f18f1ebfe2250b29c52 1474 1473 2011-01-18T11:06:29Z Hsa061 18 wikitext text/x-wiki * Information about how to come to Bergen and accomodation can be found on this link: http://www.uib.no/People/hsa061/DAMARA/Contact_Information.html * You can get a visitors account from your contact person fill in the form on https://tjinfo.uib.no/nettkonto the day you arrive. e256d72f4305ad506bdb342b45df40097948a493 0 329 1477 1448 2011-01-19T09:59:02Z Gge002 52 wikitext text/x-wiki ==Programming T&T== #C/C++ #*[[ANSI C]] T&T #*[[ISO/IEC C++]] (Unmanaged C++) T&T #*[[C++/CLI]] (Managed C++) T&T #Matlab T&T #*[[Using MEX-Files to Call C/C++ and Fortran Programs]] #[[LabVIEW T&T]] [[Category:Programming]] [[Category:Tips and Tricks]] 79bcaad9a50c48039d29d80c36a70e36d9f9f041 6 335 1478 2011-01-19T10:03:49Z Gge002 52 Function connected directly to a structure, seemingly without a tunnel or shift register. wikitext text/x-wiki Function connected directly to a structure, seemingly without a tunnel or shift register. 29325cc1c10a11f0b6afd63017d687f683d626e0 6 336 1479 2011-01-19T10:04:39Z Gge002 52 Traced connection of a function to a tunnel in the structure border wikitext text/x-wiki Traced connection of a function to a tunnel in the structure border 6284f3a60a3358f8e848da9d49e94457e530ead0 0 337 1480 2011-01-19T10:16:33Z Gge002 52 Made the page wikitext text/x-wiki [[File:LabView1.png|thumb|alt=Alternative text|Fig. 1 Function connected dierectly to the border of a structure without going through a tunnel or a shift register.]] [[File:LabView2.png|thumb|alt=Alternative text|Fig. 2 Actual connection revealed by double-clicking on the connecting wire.]] ====Function connected dierectly to the border of a structure without going through a tunnel or a shift register==== An example of the problem is shown in Fig. 1. This seems to be a bug in the graphical interface. Doubleclick on the wire coming into the function and this will reveal the actual connection (Fig. 2) 2a3f7b94f215c8fc424c2834fe02b920002687fa 0 21 1481 1452 2011-01-19T11:02:15Z Dfe002 7 updated /* Meetings and conferences */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Oliver * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 31.01. - 10.02.11: EDIT 2011 Excellence in Detectors and Instrumentation Technologies (http://cern.ch/edit2011) * 23.02. - 25.02.11: 3D workshop in Bergen * 02.05. - 06.05.11: IRTG Bergen, medical physics * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. 3fa14f10d3d6da661898bcc26b9bc72b17f2e2e1 1482 1481 2011-01-19T11:21:20Z Dfe002 7 /* Meetings and conferences */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Oliver * Postdoctors: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 31.01. - 10.02.11: EDIT 2011 Excellence in Detectors and Instrumentation Technologies, CERN (http://cern.ch/edit2011) * 23.02. - 25.02.11: 3D workshop, Bergen * 02.03. - 04.02.11: 6th "Trento" Workshop on Advanced Silicon Radiation Detectors, Trento (http://tredi.fbk.eu/) * 02.05. - 06.05.11: IRTG medical physics, Bergen * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. bda12be841518e3d7aa30a4dba06bc0c8c6d83e5 0 23 1483 1456 2011-01-19T14:27:28Z Dfe002 7 /* Documentation */ wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, ... == Documentation == [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3d/3D%20report%2006-03-09.pdf 3D Report Cedric Virmontois] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3d/Masteroppgave_kristine_helle.pdf Master thesis Kristine Helle] ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] 3d69c57c8edc7cdb7da2e63b9a95e3f4a06fcd6e 1484 1483 2011-01-19T14:29:17Z Dfe002 7 /* Documentation */ wikitext text/x-wiki == Introduction to 3D detectors == 3D detectors have three dimensional electrods going through the silicon substrate. The depletion thickness depends on p+ and n+ electrode distance. The advantages with 3D technology is: * It can operate at very low voltages * One can achieve very high radiation hardness * Very fast * Active almost to the edge Schematic drawings of the 3D detector: [[Image:3D_drawing1.png|frameless|250px]] [[Image:3D_drawing2.png|frameless|250px]] == More information == * [http://indico.cern.ch/conferenceDisplay.py?confId=27616 Testbeam talk by Erlend and Ole] * [http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=28165 3D workshop in Barcelona] * [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TJM-4J0WP4K-1&_user=596755&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000030718&_version=1&_urlVersion=0&_userid=596755&md5=e60e7a0a154b6395ba003984f046ad29 3D-state of the art] * 3D proposal by S.I. Parker C.J. Kenneyand and J. Segal (NIMA395(1997)328)] * [http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/ The home of TurboDAQ] == Our Activities == * [[TestBeam Analysis]] * 3DSensor Characteristics * 3DMeasurement System == (Rather) Frequently asked questions == [[Frequently asked questions FAQ]] == Who are we? == * In Bergen: Bjarne, Heidi, ... == Documentation == [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3d/3D%20report%2006-03-09.pdf 3D Report Cedric Virmontois]<br> [http://web.ift.uib.no/~dominik/files/detectorlabwiki/3d/Masteroppgave_kristine_helle.pdf Master thesis Kristine Helle] ==Acknowledgements== Thanks to Alessandro de la Rosa and Ole Rohne for the lots of help we received from them, and to Cedric Virmontois who made work on 3D in Bergen. [[Category:Detector lab]] 664e5397d77de4e40cd79125e6cc431a92c1edd8 2 338 1485 2011-01-19T15:19:59Z Tbu082 19 Created page with 'Jan Lindroos' wikitext text/x-wiki Jan Lindroos 70793a4e3f4430bcb26fd136fbc48b2a1bf4835a 0 317 1487 1418 2011-01-21T12:33:57Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ == Download section == fe13e30f0885013387f1a8788a48387097bb50b5 1488 1487 2011-01-21T12:44:08Z Dfe002 7 reordering wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == 7ede2dd3b7e4200c098b4189fde5442907358644 1508 1488 2011-02-17T14:00:07Z Dfe002 7 added first parts list wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064 http://www.samtec.com/search/vita57fmc.aspx 0d934c134e141a82c78d57c3b8d1766ca941ea4e 1509 1508 2011-02-17T14:00:23Z Dfe002 7 /* Shopping list */ wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 24fe89d890e19a12b5190d4f250da3efa159178f 1510 1509 2011-02-18T08:42:51Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 1fbb02a3e65b0384c10f0934d50e8ed6b7522c9e 0 339 1491 2011-02-07T08:03:50Z Hsa061 18 Created page with '== Susy Terminology == * SUSY - Supersymmetry ! * Coannihilation region - Two colliding particles annihiliate == Astrophysics Terminology == == Detector Terminology == == Com…' wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * Coannihilation region - Two colliding particles annihiliate == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 611dee415bef3a78bafd151c17aafc7ab1b32bd8 1495 1491 2011-02-07T09:33:28Z Hsa061 18 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * Coannihilation region - Two colliding particles annihiliate * Drell-Yann == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == d7171cf5d181081d7591ad19a8fd080ba684fff9 1496 1495 2011-02-07T10:12:26Z Hsa061 18 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * Coannihilation region - Two colliding particles annihiliate * Drell-Yann * �OS-SF - Opposite sign same flavour == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == c7059490fa34c21e0f66b925f350a871312e3de5 1499 1496 2011-02-12T18:20:15Z Jli051 54 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * Coannihilation region - Two colliding particles annihiliate * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * �OS-SF - Opposite sign same flavour == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 3aad2f33718949cc4b0c5d8bf6d05e7fd15a6692 1500 1499 2011-02-17T07:34:12Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * �OS-SF - Opposite sign same flavour == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 4ef4d5776747ae07f5bdc189cb2fbc8480056645 1501 1500 2011-02-17T07:36:05Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but in some model it is the gravitino. * NLSP - Next to Lightest Supersymmetric Particle * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 682144ae7b46e4a1f94aebc90c8dd348db6df2de 1503 1501 2011-02-17T07:47:06Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but in some model it is the gravitino. * NLSP - Next to Lightest Supersymmetric Particle * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SU(1) ** SU(2) == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == a9e16cbf32db8c4c3fec874b5091f69cb0008ab0 1504 1503 2011-02-17T07:54:31Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * MSSM - Minimal Supersymmetric extension of the Standard Model * mSUGRA - * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but in some model it is the gravitino. * NLSP - Next to Lightest Supersymmetric Particle * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SPS1: "Typical" mSUGRA scenario ** SPS2: "Focus point" scenario in mSUGRA ** SPS3: Model line into "coannihilation region" in mSUGRA ** SPS4: mSUGRA scenario with large tan &beta; == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 715b83b1e2171b3aac2b547dd1677f2b1468f6d0 1505 1504 2011-02-17T07:57:52Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * MSSM - Minimal Supersymmetric extension of the Standard Model * mSUGRA - * GMSB - * AMSB - * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but in some model it is the gravitino. * NLSP - Next to Lightest Supersymmetric Particle * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SPS1: "Typical" mSUGRA scenario ** SPS2: "Focus point" scenario in mSUGRA ** SPS3: Model line into "coannihilation region" in mSUGRA ** SPS4: mSUGRA scenario with large tan &beta; ** SPS5: mSUGRA scenario with relatively light scalar top quark ** SPS6: mSUGRA-like scenario with non-unified gaugino masses ** SPS7: GMSB scenario with stau NLSP ** SPS8: GMSB scenario with neutralino NLSP ** SPS9: AMSB scenario == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 4ed3c73962cdaf4420e3d64b15a11db1520307ba 1507 1505 2011-02-17T13:21:53Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * MSSM - Minimal Supersymmetric extension of the Standard Model * mSUGRA - Class of SUSY model where SUSY breaking is mediated by gravity. * GMSB - * AMSB - * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but in some model it is the gravitino. * NLSP - Next to Lightest Supersymmetric Particle * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SPS1: "Typical" mSUGRA scenario ** SPS2: "Focus point" scenario in mSUGRA ** SPS3: Model line into "coannihilation region" in mSUGRA ** SPS4: mSUGRA scenario with large tan &beta; ** SPS5: mSUGRA scenario with relatively light scalar top quark ** SPS6: mSUGRA-like scenario with non-unified gaugino masses ** SPS7: GMSB scenario with stau NLSP ** SPS8: GMSB scenario with neutralino NLSP ** SPS9: AMSB scenario == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == d590ff7bdf069bc97453d3946ec7775883c4b5a2 0 340 1493 2011-02-07T08:07:14Z Hsa061 18 Created page with '== Getting started == * ...' wikitext text/x-wiki == Getting started == * ... 9779313ef0ebea084965064bf96e89bf1c465fbd 1494 1493 2011-02-07T08:07:34Z Hsa061 18 wikitext text/x-wiki == Getting started == * ... == For analysis == * ... 2e8d86f2cdecae34a1e6bd888126a40d4f912391 1502 1494 2011-02-17T07:39:49Z St01355 57 wikitext text/x-wiki == Getting started == * Lecture notes from [[Software workshop, 09/09-09]] == For analysis == * ... bf65bcdff2f3ee486ea9bfdd2c14e7d2523eb236 0 330 1497 1451 2011-02-08T07:56:35Z Gge002 52 wikitext text/x-wiki ==Understanding MEX== MEX-files (MATLAB executables) are used to call large pre-existing C/C++ and Fortran programs from MATLAB without translating them into MATLAB. Another advantage is that C/C++ code is generally faster than MATLAB. The best source of information is MathWorks' knowledge database. To understand C/C++ Source MEX-Files and to see how to compile them see: :*[http://www.mathworks.com/help/techdoc/matlab_external/f43721.html C/C++ Source MEX-Files] (last checked 10 Jan 2011) To understand how to use MEX-Files to Call C/C++ and Fortran Programs see :*[http://www.mathworks.com/help/techdoc/matlab_external/f29502.html Using MEX-Files to Call C/C++ and Fortran Programs] (last checked 10 Jan 2011) ==Tips 'n' Tricks== #'''Where to place the gateway routine within the C/C++ program''' #*''The whole code can be placed in the Gateway routine'' #*''At the end'' - it looks like the gateway routine should be the last routine in the code if more routines are present. This sheds the problem with undefined variables and alike. I (GG) haven't found any place in the knowledge base where this is mentioned. Maybe it is not true in all cases either. Here follows an example that is a modification of the original MATLAB code from the knowledge database (see link "MEX-Files to Call C/C++ and Fortran Programs" above). In the case below three input parameters are required, while in the original code only two are necessary. A comparison between the two version helps to find the in-s and out-s. <source lang="cpp"> #include "mex.h" #include "matrix.h" /* * arrayProduct.c * Multiplies an input scalar times a 1xN matrix * and outputs a 1xN matrix * * This is a modified version of the MEX-file from MathWorks' knowledge database. * http://www.mathworks.com/help/techdoc/matlab_external/f29502.html * * The modifications are (LINE REFERENCES DIFFERENT FROM ORIGINAL): * the original "double multiplier" is replaced with "double multiplier1" (line 61) * introduced "double multiplier2" (line 62) * line 37 - added "double w" * line 42 - added " * w " * line 73 - changed message to be displayed * line 98, 99 - added those lines * line 113 - added "multiplier2" and changed "multiplier" with "multiplier1" */ /**************************************************/ /**************************************************/ /************* SOME ROUTINE *************/ /**************************************************/ /**************************************************/ /* Multiplies an input scalar times a 1xN matrix */ /* and output is a 1xN matrix */ /**************************************************/ /**************************************************/ void arrayProduct(double x, double *y, double *z, double w, mwSize n) { mwSize i; for (i=0; i<n; i++) { z[i] = x * y[i] * w; } } /**********************************************************/ /**********************************************************/ /************* THE GATEWAY FUNCTION *************/ /**********************************************************/ /**********************************************************/ void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) { /*** Variable declarations ***/ double multiplier1; // input scalar double multiplier2; // input scalar double *inMatrix; // 1xN input matrix mwSize ncols; // size of matrix double *outMatrix; // output matrix /*** CODE ***/ // check for proper number of arguments if(nrhs!=3) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nrhs", "Three inputs required."); } if(nlhs!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nlhs", "One output required."); } // make sure the first input argument is scalar if( !mxIsDouble(prhs[0]) || mxIsComplex(prhs[0]) || mxGetNumberOfElements(prhs[0])!=1 ) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notScalar", "Input multiplier must be a scalar."); } // check that number of rows in second input argument is 1 if(mxGetM(prhs[1])!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notRowVector", "Input must be a row vector."); } // get the value of the first scalar input multiplier1 = mxGetScalar(prhs[0]); // get the value of the second scalar input multiplier2 = mxGetScalar(prhs[2]); // create a pointer to the real data in the input matrix inMatrix = mxGetPr(prhs[1]); // get dimensions of the input matrix ncols = mxGetN(prhs[1]); // create the output matrix */ plhs[0] = mxCreateDoubleMatrix(1,ncols,mxREAL); // get a pointer to the real data in the output matrix outMatrix = mxGetPr(plhs[0]); // call the computational routine arrayProduct(multiplier1,inMatrix,outMatrix,multiplier2,ncols); } </source> [[Category:Programming]] [[Category:Tips and Tricks]] [[Category:MATLAB]] f16bd6a1a0c337c28d66424ea9d7e2705ce504dd 1498 1497 2011-02-08T07:58:09Z Gge002 52 wikitext text/x-wiki ==Understanding MEX== MEX-files (MATLAB executables) are used to call large pre-existing C/C++ and Fortran programs from MATLAB without translating them into MATLAB. Another advantage is that C/C++ code is generally faster than MATLAB. The best source of information is MathWorks' knowledge database. To understand C/C++ Source MEX-Files and to see how to compile them see: :*[http://www.mathworks.com/help/techdoc/matlab_external/f43721.html C/C++ Source MEX-Files] (last checked 10 Jan 2011) To understand how to use MEX-Files to Call C/C++ and Fortran Programs see :*[http://www.mathworks.com/help/techdoc/matlab_external/f29502.html Using MEX-Files to Call C/C++ and Fortran Programs] (last checked 10 Jan 2011) ==Tips 'n' Tricks== #'''Where to place the gateway routine within the C/C++ program''' #*''The whole code can be placed in the Gateway routine'' #*''At the end'' - it looks like the gateway routine should be the last routine in the code if more routines are present. This sheds the problem with undefined variables and alike. I (GG) haven't found any place in the knowledge base where this is mentioned. Maybe it is not true in all cases either. Here follows an example that is a modification of the original MATLAB code from the knowledge database (see link "MEX-Files to Call C/C++ and Fortran Programs" above). In the case below three input parameters are required, while in the original code only two are necessary. A comparison between the two version helps to find the in-s and out-s. <source lang="cpp"> #include "mex.h" #include "matrix.h" /* * arrayProduct.c * Multiplies one input scalar times a 1xN matrix, times another input scalar * and outputs a 1xN matrix * * This is a modified version of the MEX-file from MathWorks' knowledge database. * http://www.mathworks.com/help/techdoc/matlab_external/f29502.html * * The modifications are (LINE REFERENCES DIFFERENT FROM ORIGINAL): * the original "double multiplier" is replaced with "double multiplier1" (line 61) * introduced "double multiplier2" (line 62) * line 37 - added "double w" * line 42 - added " * w " * line 73 - changed message to be displayed * line 98, 99 - added those lines * line 113 - added "multiplier2" and changed "multiplier" with "multiplier1" */ /**************************************************/ /**************************************************/ /************* SOME ROUTINE *************/ /**************************************************/ /**************************************************/ /* Multiplies an input scalar times a 1xN matrix */ /* and output is a 1xN matrix */ /**************************************************/ /**************************************************/ void arrayProduct(double x, double *y, double *z, double w, mwSize n) { mwSize i; for (i=0; i<n; i++) { z[i] = x * y[i] * w; } } /**********************************************************/ /**********************************************************/ /************* THE GATEWAY FUNCTION *************/ /**********************************************************/ /**********************************************************/ void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) { /*** Variable declarations ***/ double multiplier1; // input scalar double multiplier2; // input scalar double *inMatrix; // 1xN input matrix mwSize ncols; // size of matrix double *outMatrix; // output matrix /*** CODE ***/ // check for proper number of arguments if(nrhs!=3) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nrhs", "Three inputs required."); } if(nlhs!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nlhs", "One output required."); } // make sure the first input argument is scalar if( !mxIsDouble(prhs[0]) || mxIsComplex(prhs[0]) || mxGetNumberOfElements(prhs[0])!=1 ) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notScalar", "Input multiplier must be a scalar."); } // check that number of rows in second input argument is 1 if(mxGetM(prhs[1])!=1) { mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notRowVector", "Input must be a row vector."); } // get the value of the first scalar input multiplier1 = mxGetScalar(prhs[0]); // get the value of the second scalar input multiplier2 = mxGetScalar(prhs[2]); // create a pointer to the real data in the input matrix inMatrix = mxGetPr(prhs[1]); // get dimensions of the input matrix ncols = mxGetN(prhs[1]); // create the output matrix */ plhs[0] = mxCreateDoubleMatrix(1,ncols,mxREAL); // get a pointer to the real data in the output matrix outMatrix = mxGetPr(plhs[0]); // call the computational routine arrayProduct(multiplier1,inMatrix,outMatrix,multiplier2,ncols); } </source> [[Category:Programming]] [[Category:Tips and Tricks]] [[Category:MATLAB]] fa736a74a3f07615744effbb2fbaa100b609d352 2 341 1506 2011-02-17T12:27:48Z Tbu082 19 Created page with 'Trygve Buanes' wikitext text/x-wiki Trygve Buanes 7f817bd175d7cfbce037f316f2bc9ac8e8371107 0 317 1511 1510 2011-02-18T08:59:44Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 732ec45788ed649ae70ce6fc480aa79930066710 1512 1511 2011-02-18T09:56:46Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31 2x USB cables - F1076669 - F1308878 851ce7a5d71152cbcba4275b7771124221a13727 1513 1512 2011-02-18T09:57:00Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 b934c3e397a97ca23eec3510b0a61541b03de5c9 1517 1513 2011-02-21T07:00:20Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == == Readout electronics == === Adapterboard /Fanoutboard === The schematics of the board can be found here: [http://web.ift.uib.no/~dominik/files/focal/Adapter.pdf Adapterboard] === Spartanboard === === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 5cef4b154b58c0551cf110acc16fa8cfa03dee64 1535 1517 2011-04-07T14:59:23Z Nfyku 4 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:Mimosa Phase-1]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The schematics of the boards is here: [[File:Adapter board]]. === Spartanboard === === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 7996596a50f25e75c3867e56faf8508b09e9b9a7 1537 1535 2011-04-07T15:06:02Z Nfyku 4 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080724.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The schematics of the boards is here: [[File:Adapter board ]]. === Spartanboard === === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board would run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Xirtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 cca5e1dcc732d0284d37ee70416760c84ea1c2db 1539 1537 2011-04-07T15:11:35Z Nfyku 4 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080724.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 f843b28f8d71b6798714355b1a2f8efbad523a94 1544 1539 2011-04-12T08:37:34Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 433f0c2b7263a7cb42c5fe989f9bdbac2462c910 1546 1544 2011-04-12T08:42:13Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 2218752956292c9b38a1e1b904b6f24e4b2fa8f1 1547 1546 2011-04-12T08:44:23Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [Xilinx Virtex 6 development board] http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 88799713d4166c66573a669539f793011f04cce8 1548 1547 2011-04-12T08:45:09Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [[Xilinx Virtex 6 development board] http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm ]as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 befe5f49a5023ea6f69f515f56539d5ad49fc9da 1549 1548 2011-04-12T08:45:36Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [[Xilinx Virtex 6 development board:http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm ]]as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 54dbf16be5a5cb60d2a11149e04da9f6f38bd9a2 1550 1549 2011-04-12T08:46:09Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [[Xilinx Virtex 6 development board]:http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm ]as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 7474ceb6a305c148bbbce4cf80088de594cd5060 1551 1550 2011-04-12T08:54:06Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a <a href="http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm">Xilinx Virtex 6 development board</a> as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 fa42803277a0831b2bbe2b549ad8c0c93244995d 1552 1551 2011-04-12T08:55:25Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a Xilinx Virtex 6 development board as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 433f0c2b7263a7cb42c5fe989f9bdbac2462c910 1554 1552 2011-04-12T09:00:03Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [[Xilinx Virtex 6 development board]] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 1dbbf4a91c55f8ece4156440088c6d69bf8e50e1 1555 1554 2011-04-12T09:05:42Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 3ff10bd0c33a1ef3d7dc4c0f80e94eb23b74958d 1556 1555 2011-04-12T09:24:15Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf|preliminary data sheet]] == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 30b02748f31ef47c24c669797b6127334e08acab 1557 1556 2011-04-12T09:24:43Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 114352005f86464908a0fca6a09fd6f29476481e 1558 1557 2011-04-12T09:33:12Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[File:PH1-UserMan-20080916.pdf|manual]] preliminary data sheet == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. The schematics of the boards is here: [[File:Focal_read-out_board_schematics.pdf]]. === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 a01d910527563fe517e633b6f3f5b8a9b5685125 1559 1558 2011-04-12T09:48:53Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == [[Media:PH1-UserMan-20080916.pdf|preliminary data sheet]] == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 85778a2b03c079894c0362946f8b6142b506c45a 0 339 1514 1507 2011-02-18T11:07:11Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * MSSM - Minimal Supersymmetric extension of the Standard Model * mSUGRA - Class of SUSY model where SUSY breaking is mediated by gravity. * GMSB - * AMSB - * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but may be other particles (gravition, axino, ...) in some models * NLSP - Next to Lightest Supersymmetric Particle * LOSP - Lightest Ordinary Supersymmetric Particle * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SPS1: "Typical" mSUGRA scenario ** SPS2: "Focus point" scenario in mSUGRA ** SPS3: Model line into "coannihilation region" in mSUGRA ** SPS4: mSUGRA scenario with large tan &beta; ** SPS5: mSUGRA scenario with relatively light scalar top quark ** SPS6: mSUGRA-like scenario with non-unified gaugino masses ** SPS7: GMSB scenario with stau NLSP ** SPS8: GMSB scenario with neutralino NLSP ** SPS9: AMSB scenario == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 70da57aa76d7f133ddcfa83d34b38ee04a0e0ee4 1515 1514 2011-02-18T11:09:08Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * MSSM - Minimal Supersymmetric extension of the Standard Model * mSUGRA - Class of SUSY model where SUSY breaking is mediated by gravity. * GMSB - * AMSB - * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but may be other particles (gravition, axino, ...) in some models * NLSP - Next to Lightest Supersymmetric Particle * LOSP - Lightest Ordinary/Observable Supersymmetric Particle, relevant in models where LSP is in a hidden sector * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SPS1: "Typical" mSUGRA scenario ** SPS2: "Focus point" scenario in mSUGRA ** SPS3: Model line into "coannihilation region" in mSUGRA ** SPS4: mSUGRA scenario with large tan &beta; ** SPS5: mSUGRA scenario with relatively light scalar top quark ** SPS6: mSUGRA-like scenario with non-unified gaugino masses ** SPS7: GMSB scenario with stau NLSP ** SPS8: GMSB scenario with neutralino NLSP ** SPS9: AMSB scenario == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 9fa9696458f7f1f490652410f8ec5f463530f093 1516 1515 2011-02-18T11:09:42Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * MSSM - Minimal Supersymmetric extension of the Standard Model * mSUGRA - Class of SUSY model where SUSY breaking is mediated by gravity. * GMSB - * AMSB - * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but may be other particles (gravition, axino, ...) in some models. LSP is assumed to be stable in moste models. * NLSP - Next to Lightest Supersymmetric Particle * LOSP - Lightest Ordinary/Observable Supersymmetric Particle, relevant in models where LSP is in a hidden sector * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SPS1: "Typical" mSUGRA scenario ** SPS2: "Focus point" scenario in mSUGRA ** SPS3: Model line into "coannihilation region" in mSUGRA ** SPS4: mSUGRA scenario with large tan &beta; ** SPS5: mSUGRA scenario with relatively light scalar top quark ** SPS6: mSUGRA-like scenario with non-unified gaugino masses ** SPS7: GMSB scenario with stau NLSP ** SPS8: GMSB scenario with neutralino NLSP ** SPS9: AMSB scenario == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 2b35b51f9221d5ff65493a08a2d017f071be3560 1518 1516 2011-02-21T12:46:21Z St01355 57 wikitext text/x-wiki == Susy Terminology == * SUSY - Supersymmetry ! * MSSM - Minimal Supersymmetric extension of the Standard Model * mSUGRA - Class of SUSY model where SUSY breaking is mediated by gravity. * GMSB - Gauge Mediated SUSY breaking * AMSB - * LSP - Lightest Supersymmetric Particle. In most model the lightest neutralino is LSP, but may be other particles (gravition, axino, ...) in some models. LSP is assumed to be stable in moste models. * NLSP - Next to Lightest Supersymmetric Particle * LOSP - Lightest Ordinary/Observable Supersymmetric Particle, relevant in models where LSP is in a hidden sector * Coannihilation region - Region in SUSY parameters space where the mass difference between NLSP and LSP is small (few GeV). This enhances the probability of NLSP and LSP annihilating with each other bringing the relic density down to a level consistent with astrophysical observations. * Drell-Yan process - Quark+anti-quark -> Z/photon -> lepton+anti-lepton * OS-SF - Opposite sign same flavour * SUSY benchmark points - points in SUSY parameter space which are chosen as test points in simulation studies. The benchmark points are chosen such that they are representative for different regions of the parameter space ** SPS1: "Typical" mSUGRA scenario ** SPS2: "Focus point" scenario in mSUGRA ** SPS3: Model line into "coannihilation region" in mSUGRA ** SPS4: mSUGRA scenario with large tan &beta; ** SPS5: mSUGRA scenario with relatively light scalar top quark ** SPS6: mSUGRA-like scenario with non-unified gaugino masses ** SPS7: GMSB scenario with stau NLSP ** SPS8: GMSB scenario with neutralino NLSP ** SPS9: AMSB scenario == Astrophysics Terminology == == Detector Terminology == == Computing Terminology == 6c261641ea0394e2b09c44dea86bcd902445824e 0 331 1519 1492 2011-03-01T10:18:29Z Jli051 54 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Other stuff: * [[Useful Linux commands]] * <a href="http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf">Small intro to Linux (pdf)</a> 1259eefd2c43b8de416b62da4750cb1dd56e2bd5 1520 1519 2011-03-01T10:19:44Z Jli051 54 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Other stuff: * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] 2df1062f4457b9ed16454397b114c626b1c3744b 1521 1520 2011-03-01T10:25:45Z Jli051 54 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] 5de3855dce89d448b0c51daf2829568e4af7dafd 1522 1521 2011-03-08T16:05:07Z Jli051 54 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * Info about D3PD analysis variables * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] 070af48cd2352426c99050a0545a75c99b02b198 1526 1522 2011-03-08T16:24:56Z Jli051 54 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] 6c0350c400a0ced10cb345015955f6e16ffc30c8 1560 1526 2011-04-13T15:14:32Z St01355 57 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] == [[Results]] == * [[Publications|Results#Publications] * [[Theses]] * [[Presentations]] 1b4e904424e2a93df7ed557b12a780dcf87ccd1b 1567 1560 2011-04-13T15:36:33Z St01355 57 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] == [[Results]] == * [[Results#Publications|Publications]] * [[Theses]] * [[Presentations]] e44202efdda243e3674677cb8a8baff6bdbbedca 0 343 1527 2011-03-08T16:27:23Z Jli051 54 Created page with '== Analysis variables == '''Meta-data''' int RunNumber; '''Trigger''' float trig_EF_met_MEx; float trig_EF_met_MEy; int trig_L2_jet_n; std::vector<float>* trig_L2_jet_pt…' wikitext text/x-wiki == Analysis variables == '''Meta-data''' int RunNumber; '''Trigger''' float trig_EF_met_MEx; float trig_EF_met_MEy; int trig_L2_jet_n; std::vector<float>* trig_L2_jet_pt; bool L1_J55; '''Jet''' int jet_n; ''Number of jets in event (extra conditions?)'' std::vector<float>* jet_eta; std::vector<float>* jet_phi; std::vector<float>* jet_m; std::vector<float>* jet_flavor_weight_SV0; std::vector<float>* jet_pt; ''Transverse momentum of jets'' std::vector<float>* jet_emscale_pt; std::vector<float>* jet_n90; std::vector<float>* jet_timing; std::vector<float>* jet_quality; std::vector<float>* jet_emfrac; std::vector<float>* jet_hecf; std::vector<float>* jet_EMJES; std::vector<float>* jet_jvtxf; std::vector<float>* jet_fmax; '''Vertex''' std::vector<int>* vx_nTracks; '''Missing transverse energy''' float MET_Final_et; float MET_Final_etx; float MET_Final_ety; float MET_Final_phi; float MET_Final_sumet; float MET_LocHadTopo_etx; float MET_MuonBoy_etx; float MET_LocHadTopo_ety; float MET_MuonBoy_ety; '''Electron''' int el_n; std::vector<int>* el_author; std::vector<float>* el_pt; std::vector<float>* el_eta; std::vector<float>* el_phi; std::vector<float>* el_cl_eta; std::vector<float>* el_cl_phi; std::vector<int>* el_goodOQ; '''Muon''' int mu_staco_n; std::vector<float>* mu_staco_matchchi2; std::vector<float>* mu_staco_isCombinedMuon; std::vector<float>* mu_staco_pt; std::vector<float>* mu_staco_eta; std::vector<float>* mu_staco_phi; std::vector<float>* mu_staco_ptcone20; std::vector<float>* mu_staco_me_qoverp_exPV; std::vector<float>* mu_staco_me_theta_exPV; std::vector<float>* mu_staco_id_qoverp_exPV; std::vector<float>* mu_staco_id_theta_exPV; '''Tau''' int tau_n; std::vector<float>* tau_Et; std::vector<float>* tau_eta; std::vector<float>* tau_phi; std::vector<float>* tau_m; std::vector<int>* tau_nLooseTrk; std::vector<int>* tau_nProng; std::vector<int>* tau_numTrack; std::vector<float>* tau_secvtx_chiSquared; std::vector<float>* tau_secvtx_numberDoF; std::vector<float>* tau_secvtx_x; std::vector<float>* tau_secvtx_y; std::vector<float>* tau_secvtx_z; std::vector<int>* tau_BDTEleScore; std::vector<float>* tau_BDTJetScore; std::vector<float>* tau_electronVetoTight; std::vector<float>* tau_muonVeto; std::vector<float>* tau_charge; std::vector<float>* tau_seedCalo_etEMCalib; std::vector<float>* tau_seedCalo_etHadCalib; 4953e78ad0b400c17e0f25919745c1b143625131 1528 1527 2011-03-08T16:36:07Z Jli051 54 wikitext text/x-wiki Please feel free to add more variables and what they contain. == Analysis variables == '''Meta-data''' int RunNumber; '''Trigger''' float trig_EF_met_MEx; float trig_EF_met_MEy; int trig_L2_jet_n; std::vector<float>* trig_L2_jet_pt; bool L1_J55; '''Jet''' int jet_n; ''Number of jets in event (extra conditions?)'' std::vector<float>* jet_eta; std::vector<float>* jet_phi; std::vector<float>* jet_m; std::vector<float>* jet_flavor_weight_SV0; std::vector<float>* jet_pt; ''Transverse momentum of jets in MeV'' std::vector<float>* jet_emscale_pt; std::vector<float>* jet_n90; std::vector<float>* jet_timing; std::vector<float>* jet_quality; std::vector<float>* jet_emfrac; std::vector<float>* jet_hecf; std::vector<float>* jet_EMJES; std::vector<float>* jet_jvtxf; std::vector<float>* jet_fmax; '''Vertex''' std::vector<int>* vx_nTracks; '''Missing transverse energy''' float MET_Final_et; '' Total amount of missing E_T in MeV '' float MET_Final_etx; float MET_Final_ety; float MET_Final_phi; float MET_Final_sumet; float MET_LocHadTopo_etx; float MET_MuonBoy_etx; float MET_LocHadTopo_ety; float MET_MuonBoy_ety; '''Electron''' int el_n; '' Number of electrons in event'' std::vector<int>* el_author; std::vector<float>* el_pt; ''Transverse momentum of electrons in MeV'' std::vector<float>* el_eta; std::vector<float>* el_phi; std::vector<float>* el_cl_eta; std::vector<float>* el_cl_phi; std::vector<int>* el_goodOQ; '''Muon''' int mu_staco_n; std::vector<float>* mu_staco_matchchi2; std::vector<float>* mu_staco_isCombinedMuon; std::vector<float>* mu_staco_pt; std::vector<float>* mu_staco_eta; std::vector<float>* mu_staco_phi; std::vector<float>* mu_staco_ptcone20; std::vector<float>* mu_staco_me_qoverp_exPV; std::vector<float>* mu_staco_me_theta_exPV; std::vector<float>* mu_staco_id_qoverp_exPV; std::vector<float>* mu_staco_id_theta_exPV; '''Tau''' int tau_n; '' Number of taus '' std::vector<float>* tau_Et; ''Transverse energy of taus in MeV'' std::vector<float>* tau_eta; std::vector<float>* tau_phi; std::vector<float>* tau_m; std::vector<int>* tau_nLooseTrk; std::vector<int>* tau_nProng; std::vector<int>* tau_numTrack; std::vector<float>* tau_secvtx_chiSquared; std::vector<float>* tau_secvtx_numberDoF; std::vector<float>* tau_secvtx_x; std::vector<float>* tau_secvtx_y; std::vector<float>* tau_secvtx_z; std::vector<int>* tau_BDTEleScore; std::vector<float>* tau_BDTJetScore; std::vector<float>* tau_electronVetoTight; std::vector<float>* tau_muonVeto; std::vector<float>* tau_charge; std::vector<float>* tau_seedCalo_etEMCalib; std::vector<float>* tau_seedCalo_etHadCalib; 4596f4b492a64150dc755ddeabb9c416b49bb659 1529 1528 2011-03-14T10:50:15Z Jli051 54 wikitext text/x-wiki Please feel free to add more variables and what they contain. == Analysis variables == '''Meta-data''' int RunNumber; '''Trigger''' float trig_EF_met_MEx; float trig_EF_met_MEy; int trig_L2_jet_n; std::vector<float>* trig_L2_jet_pt; bool L1_J55; '''Jet''' int jet_n; ''Number of jets in event (extra conditions?)'' std::vector<float>* jet_eta; std::vector<float>* jet_phi; std::vector<float>* jet_m; std::vector<float>* jet_flavor_weight_SV0; std::vector<float>* jet_pt; ''Transverse momentum of jets in MeV'' std::vector<float>* jet_emscale_pt; std::vector<float>* jet_n90; ''minimum number of cells containing at least 90% of the jet energy'' std::vector<float>* jet_timing; std::vector<float>* jet_quality; std::vector<float>* jet_emfrac; ''Energy fraction that is due to electrons and photons'' std::vector<float>* jet_hecf; ''Energy fraction deposited in hadronic endcap calorimeter (HEC) std::vector<float>* jet_EMJES; std::vector<float>* jet_jvtxf; std::vector<float>* jet_fmax; '''Vertex''' std::vector<int>* vx_nTracks; '''Missing transverse energy''' float MET_Final_et; '' Total amount of missing E_T in MeV '' float MET_Final_etx; float MET_Final_ety; float MET_Final_phi; float MET_Final_sumet; float MET_LocHadTopo_etx; float MET_MuonBoy_etx; float MET_LocHadTopo_ety; float MET_MuonBoy_ety; '''Electron''' int el_n; '' Number of electrons in event'' std::vector<int>* el_author; std::vector<float>* el_pt; ''Transverse momentum of electrons in MeV'' std::vector<float>* el_eta; std::vector<float>* el_phi; std::vector<float>* el_cl_eta; std::vector<float>* el_cl_phi; std::vector<int>* el_goodOQ; '''Muon''' int mu_staco_n; std::vector<float>* mu_staco_matchchi2; std::vector<float>* mu_staco_isCombinedMuon; std::vector<float>* mu_staco_pt; std::vector<float>* mu_staco_eta; std::vector<float>* mu_staco_phi; std::vector<float>* mu_staco_ptcone20; std::vector<float>* mu_staco_me_qoverp_exPV; std::vector<float>* mu_staco_me_theta_exPV; std::vector<float>* mu_staco_id_qoverp_exPV; std::vector<float>* mu_staco_id_theta_exPV; '''Tau''' int tau_n; '' Number of taus '' std::vector<float>* tau_Et; ''Transverse energy of taus in MeV'' std::vector<float>* tau_eta; std::vector<float>* tau_phi; std::vector<float>* tau_m; std::vector<int>* tau_nLooseTrk; std::vector<int>* tau_nProng; std::vector<int>* tau_numTrack; std::vector<float>* tau_secvtx_chiSquared; std::vector<float>* tau_secvtx_numberDoF; std::vector<float>* tau_secvtx_x; std::vector<float>* tau_secvtx_y; std::vector<float>* tau_secvtx_z; std::vector<int>* tau_BDTEleScore; std::vector<float>* tau_BDTJetScore; std::vector<float>* tau_electronVetoTight; std::vector<float>* tau_muonVeto; std::vector<float>* tau_charge; std::vector<float>* tau_seedCalo_etEMCalib; std::vector<float>* tau_seedCalo_etHadCalib; 4457492e1e0890028111baa410a9b9bd94b81a3a 1530 1529 2011-03-14T10:52:29Z Jli051 54 wikitext text/x-wiki Please feel free to add more variables and what they contain. == Analysis variables == '''Meta-data''' int RunNumber; '''Trigger''' float trig_EF_met_MEx; float trig_EF_met_MEy; int trig_L2_jet_n; std::vector<float>* trig_L2_jet_pt; bool L1_J55; ''Level 1 Jet trigger (jet energy>55 GeV ?) '''Jet''' int jet_n; ''Number of jets in event (extra conditions?)'' std::vector<float>* jet_eta; std::vector<float>* jet_phi; std::vector<float>* jet_m; std::vector<float>* jet_flavor_weight_SV0; std::vector<float>* jet_pt; ''Transverse momentum of jets in MeV'' std::vector<float>* jet_emscale_pt; std::vector<float>* jet_n90; ''minimum number of cells containing at least 90% of the jet energy'' std::vector<float>* jet_timing; std::vector<float>* jet_quality; std::vector<float>* jet_emfrac; ''Energy fraction that is due to electrons and photons'' std::vector<float>* jet_hecf; ''Energy fraction deposited in hadronic endcap calorimeter (HEC) std::vector<float>* jet_EMJES; std::vector<float>* jet_jvtxf; std::vector<float>* jet_fmax; '''Vertex''' std::vector<int>* vx_nTracks; '''Missing transverse energy''' float MET_Final_et; '' Total amount of missing E_T in MeV '' float MET_Final_etx; float MET_Final_ety; float MET_Final_phi; float MET_Final_sumet; float MET_LocHadTopo_etx; float MET_MuonBoy_etx; float MET_LocHadTopo_ety; float MET_MuonBoy_ety; '''Electron''' int el_n; '' Number of electrons in event'' std::vector<int>* el_author; std::vector<float>* el_pt; ''Transverse momentum of electrons in MeV'' std::vector<float>* el_eta; std::vector<float>* el_phi; std::vector<float>* el_cl_eta; std::vector<float>* el_cl_phi; std::vector<int>* el_goodOQ; '''Muon''' int mu_staco_n; std::vector<float>* mu_staco_matchchi2; std::vector<float>* mu_staco_isCombinedMuon; std::vector<float>* mu_staco_pt; std::vector<float>* mu_staco_eta; std::vector<float>* mu_staco_phi; std::vector<float>* mu_staco_ptcone20; std::vector<float>* mu_staco_me_qoverp_exPV; std::vector<float>* mu_staco_me_theta_exPV; std::vector<float>* mu_staco_id_qoverp_exPV; std::vector<float>* mu_staco_id_theta_exPV; '''Tau''' int tau_n; '' Number of taus '' std::vector<float>* tau_Et; ''Transverse energy of taus in MeV'' std::vector<float>* tau_eta; std::vector<float>* tau_phi; std::vector<float>* tau_m; std::vector<int>* tau_nLooseTrk; std::vector<int>* tau_nProng; std::vector<int>* tau_numTrack; std::vector<float>* tau_secvtx_chiSquared; std::vector<float>* tau_secvtx_numberDoF; std::vector<float>* tau_secvtx_x; std::vector<float>* tau_secvtx_y; std::vector<float>* tau_secvtx_z; std::vector<int>* tau_BDTEleScore; std::vector<float>* tau_BDTJetScore; std::vector<float>* tau_electronVetoTight; std::vector<float>* tau_muonVeto; std::vector<float>* tau_charge; std::vector<float>* tau_seedCalo_etEMCalib; std::vector<float>* tau_seedCalo_etHadCalib; 4407a43cddd74542356a22ad32febd91556ab4b2 0 21 1531 1482 2011-03-29T09:08:52Z Hsa061 18 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Oliver * Postdoctors: Trygve * Researcher: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre * Phone number: 55588306 == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332. * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 31.01. - 10.02.11: EDIT 2011 Excellence in Detectors and Instrumentation Technologies, CERN (http://cern.ch/edit2011) * 23.02. - 25.02.11: 3D workshop, Bergen * 02.03. - 04.02.11: 6th "Trento" Workshop on Advanced Silicon Radiation Detectors, Trento (http://tredi.fbk.eu/) * 02.05. - 06.05.11: IRTG medical physics, Bergen * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. 2f40f35ae7819090fe48d1f13336b2806e0a5364 1532 1531 2011-03-29T09:09:40Z Hsa061 18 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Oliver * Postdoctors: Trygve * Researcher: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332 (55588306) * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 31.01. - 10.02.11: EDIT 2011 Excellence in Detectors and Instrumentation Technologies, CERN (http://cern.ch/edit2011) * 23.02. - 25.02.11: 3D workshop, Bergen * 02.03. - 04.02.11: 6th "Trento" Workshop on Advanced Silicon Radiation Detectors, Trento (http://tredi.fbk.eu/) * 02.05. - 06.05.11: IRTG medical physics, Bergen * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. 1f6c75d8faa763b9fd7c48c30a857c0b82550db0 1533 1532 2011-04-01T08:12:36Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Oliver * Postdoctors: Trygve * Researcher: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332 (55588306) * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 02.05. - 06.05.11: IRTG medical physics, Bergen * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. 65c8a029f07e04e6af836faaae21eaedb4e165d4 1534 1533 2011-04-01T08:23:49Z Dfe002 7 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Laura, Ben * Postdoctors: Trygve * Researcher: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332 (55588306) * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 02.05. - 06.05.11: IRTG medical physics, Bergen * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. f8ce350c2958043c076ac4068ac1edf2df62b894 6 345 1538 2011-04-07T15:08:04Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1545 1538 2011-04-12T08:38:19Z Sya081 50 uploaded a new version of "[[File:Focal read-out board schematics.pdf]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 346 1542 2011-04-12T08:34:35Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1543 1542 2011-04-12T08:35:38Z Sya081 50 uploaded a new version of "[[File:PH1-UserMan-20080916.pdf]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 348 1561 2011-04-13T15:16:13Z St01355 57 Created page with '== Publications == == Theses == == Internal notes == == Presentations == == Outreach ==' wikitext text/x-wiki == Publications == == Theses == == Internal notes == == Presentations == == Outreach == c5285f1bdb1d30c8d9ffaf6fe671c3da3366abf7 1562 1561 2011-04-13T15:17:29Z St01355 57 wikitext text/x-wiki == Publications == == Theses == == Internal notes == == Presentations == === Conferences === === Seminars etc === === Working groups etc === == Outreach == 0fb34d79efc6fb05868fb5a9d37a6e3d18788ce1 1563 1562 2011-04-13T15:17:50Z St01355 57 wikitext text/x-wiki == Publications == == Theses == == Internal notes == == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Outreach == e45ba0cdcfc4dc682584d603e32d2fe513aa5102 1564 1563 2011-04-13T15:31:04Z St01355 57 wikitext text/x-wiki == Publications == == Theses == == Internal notes == == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Outreach == Verdens største mikroskop – om ATLAS-eksperimentet på CERN, Trygve Buanes, [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] 26fb5a8af8996cb5989b44138ebb0a08712f5350 1565 1564 2011-04-13T15:31:58Z St01355 57 wikitext text/x-wiki == Publications == == Theses == == Internal notes == == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', Trygve Buanes, [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] 648b2bb3123ebed60d14acc11ad873a7a5a74739 1566 1565 2011-04-13T15:32:34Z St01355 57 wikitext text/x-wiki == Publications == == Theses == == Internal notes == == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011], Trygve Buanes ec673df64ca06f45d47a4f2e071adac09740d327 0 331 1568 1567 2011-04-13T15:38:58Z St01355 57 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] == [[Results]] == * [[Results#Outreach|Outreach]] * [[Results#Presentations|Presentations]] * [[Results#Publications|Publications]] * [[Results#Theses|Theses]] f923eec74914153a4995438e041f692bb7999a14 1577 1568 2011-04-15T09:23:08Z St01355 57 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 6278c2cb9b22f0d4c9ad0c93c017887a2b393030 0 348 1569 1566 2011-04-13T15:40:09Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011], Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === 228bf5ce46fe930f6b42a3a07c21ccb7c7331805 1570 1569 2011-04-13T15:42:17Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011], Trygve Buanes * ''Masterprogrammer i partikkelfysikk, [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk|Fellesseminar/infomøte], Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === c96adca11506a4ad98846ade915d46eadce8a57b 1571 1570 2011-04-13T15:43:59Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011], 13. mars 2011, Trygve Buanes * ''Masterprogrammer i partikkelfysikk, [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte], 18.mars 2011, Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === 5c51a416d16cf7f91989612439cc7313f3d10679 1572 1571 2011-04-13T15:44:31Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18.mars 2011), Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === 2eb775d2e9a6f32a0e124e632dcb8e71f9596c92 1573 1572 2011-04-15T08:32:44Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18.mars 2011), Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === 1f9456f5aebad9ba7fe795ae2e6a75fc3063ea11 1574 1573 2011-04-15T08:33:02Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18.mars 2011), Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === f7bab8805fb3083f91fa829474d31e279cf1bf96 1575 1574 2011-04-15T09:21:47Z St01355 57 moved [[Results]] to [[DamaraResults]] wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18.mars 2011), Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === f7bab8805fb3083f91fa829474d31e279cf1bf96 1606 1575 2011-06-23T12:15:20Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18.mars 2011), Trygve Buanes == Presentations == === Conferences === === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === 67472eba808183b1ae7447c88fcba37b1e9d1e8c 1608 1606 2011-06-27T12:21:19Z Jli051 54 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18.mars 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === d643e919a9db452719ebea4e04d75ace697de1b5 0 349 1576 2011-04-15T09:21:47Z St01355 57 moved [[Results]] to [[DamaraResults]] wikitext text/x-wiki #REDIRECT [[DamaraResults]] 7d1965c1d7fc4a397d157d7e14c509f215b1b519 6 350 1578 2011-05-12T11:57:41Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 317 1579 1559 2011-05-12T11:59:09Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]] == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 3e5322a4adf6bca806cf094dbc7cc45d81f603a1 1589 1579 2011-05-12T13:05:22Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 d0a83b02dc7a35f327dc537e4092d3d0fef9af95 1590 1589 2011-05-12T13:05:57Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 21f4d0fb7c501ee89266813bf8bd069c52102adb 1591 1590 2011-05-12T13:23:19Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 d90286d8df361749658e41138d39ae1ed6548460 1594 1591 2011-06-15T09:27:14Z Lbr088 56 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ [[Setting_Up_PetaLinux_System]] Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 [[Category:Mikroelektronikk]] 0681f631cd8ede8e708ded6834c15d05d73e2cad 1595 1594 2011-06-15T09:28:15Z Lbr088 56 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ [[Setting Up PetaLinux System]] Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] == Download section == #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 [[Category:Mikroelektronikk]] b96d06caab267a9408d8d7005e4265a5ed9f8604 6 351 1580 2011-05-12T12:16:56Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1592 1580 2011-05-13T16:28:11Z Sya081 50 uploaded a new version of "[[File:Pattern test.svf.txt]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1593 1592 2011-05-13T16:32:34Z Sya081 50 uploaded a new version of "[[File:Pattern test.svf.txt]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 352 1581 2011-05-12T12:34:18Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 353 1582 2011-05-12T12:46:50Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 354 1583 2011-05-12T12:50:39Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 355 1584 2011-05-12T12:50:50Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 356 1585 2011-05-12T12:54:25Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 357 1586 2011-05-12T12:58:38Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 358 1587 2011-05-12T12:58:52Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 359 1588 2011-05-12T13:04:17Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 360 1596 2011-06-22T12:52:01Z Nfyku 4 Created page with '* [[Base_System_Petalinux]] * [[XMD]] * [[Usb-driver]] * [[Troubleshoot]] * [[Webserver]] * [[CGI]] * [[JTAG]]' wikitext text/x-wiki * [[Base_System_Petalinux]] * [[XMD]] * [[Usb-driver]] * [[Troubleshoot]] * [[Webserver]] * [[CGI]] * [[JTAG]] 1b923aec87e5f43cb5a5159e362817f0731b251b 1603 1596 2011-06-22T13:02:11Z Nfyku 4 wikitext text/x-wiki * [[Base_System_Petalinux]] * [[XMD]] * [[Usb-driver]] * [[Troubleshoot]] * [[Webserver]] * [[JTAG]] [[Category:Embedded]] 806467fbefa8baf2cdbd778a53909f1b9908bc5e 0 361 1597 2011-06-22T12:52:20Z Nfyku 4 Created page with '== Create PetaLinux Platform == <pre> $ petalinux-new-platform -c <cpu-arch> -v <VENDOR> -p <PLATFORM> </pre> * -c <cpu type> As of PetaLinux 1.3, supported CPU types are 'microb…' wikitext text/x-wiki == Create PetaLinux Platform == <pre> $ petalinux-new-platform -c <cpu-arch> -v <VENDOR> -p <PLATFORM> </pre> * -c <cpu type> As of PetaLinux 1.3, supported CPU types are 'microblaze' and 'ppc440'. * -v <VENDOR> This is the vendor name – often you will use your company's name * -p <PLATFORM> The name of the platform or product you are building. The configuration files of the software platform are created in the directory ''$PETALINUX/software/petalinux-dist/vendors/<VENDOR>/<PLATFORM>.'' The new platform is automatically selected when running the petalinux-new-platform command, so there is no need to launch the toplevel configuration menu, and select the new platform. == Configure Software Platform == Generate the hardware configuration files and copy the configuration files to the right place in PetaLinux. <pre> $ cd /opt/petalinux-v1.3-final-full/hardware/user-platforms/YourProject $ petalinux-copy-autoconfig </pre> Launch the Linux kernel configuration menu and do some configuration if needed. <pre> $ petalinux-config-kernel </pre> Launch the user applications and system settings configuration menu. <pre> $ petalinux-config-apps </pre> == Build PetaLinux == This step take some time <pre> $ cd $PETALINUX/software/petalinux-dist $ make </pre> The compilation log stores in ''build.log'' file in the ''petalinux-dist/'' directory. == Run On Board == Run XMD by typing ''xmd'' in the terminal. Downlad the hardware bitstream to the fpga and connect to the board. <pre> XMD% fpga -f /opt/petalinux-v1.3-final-full/hardware/user-platforms/YourProject/implementation/download.bit XMD% connect mb mdm -debugdevice devicenr # </pre> Check the value of ''Instruction Cache Base Address'', i.e.: * Instruction Cache Base Address.....0xb0000000 Download PetaLinux binary image to board at the instruction cache base address, set program counter to that location and tell the board to start/continue. <pre> XMD% dow -data /opt/petalinux-v1.3-final-full/software/petalinux-dist/images/linux.bin 0xb0000000 XMD% rwr pc 0xb0000000 XMD% con </pre> Connect to UART with settings 115200 8-N-1. Log in as "root" with password "root". Have fun! == Digilent Atlys == When using XMD on the Atlys, it is necessary to provide extra statements to communicate with the hardware: -cable type xilinx_plugin modulename digilent_plugin i.e. fpga -f download.bit -cable type xilinx_plugin modulename digilent_plugin connect mb mdm -cable type xilinx_plugin modulename digilent_plugin From here you just do as usual, i.e. dow -data linux.bin 0xb0000000 <...> == ISE DS Version 13.1 == === Ethernet MAC Address === The MAC address is randomized by default. Use the PetaLinux System Configuration Menu to specify the new MAC address. $ petalinux-config-apps System Settings ---> Network Addresses Untick "Randomise MAC address" and enter appropriate MAC address in the next field. Exit and save. Rebuild U-boot and the images within PetaLinux: [petalinux/software/petalinux-dist]$ make u-boot image New in platform configuration $ petalinux-platform-config --update [http://www.petalogix.com/resources/documentation/petalinux/userguide/Bootloaders/UBoot/UBMacStorage PetaLinux User Guide - Updating Ethernet MAC Address] [[Category:PROVA60]] c01bdf17a759bbe63c4340c6cf2e1045606bb45c 1604 1597 2011-06-22T13:03:02Z Nfyku 4 wikitext text/x-wiki == Create PetaLinux Platform == <pre> $ petalinux-new-platform -c <cpu-arch> -v <VENDOR> -p <PLATFORM> </pre> * -c <cpu type> As of PetaLinux 1.3, supported CPU types are 'microblaze' and 'ppc440'. * -v <VENDOR> This is the vendor name – often you will use your company's name * -p <PLATFORM> The name of the platform or product you are building. The configuration files of the software platform are created in the directory ''$PETALINUX/software/petalinux-dist/vendors/<VENDOR>/<PLATFORM>.'' The new platform is automatically selected when running the petalinux-new-platform command, so there is no need to launch the toplevel configuration menu, and select the new platform. == Configure Software Platform == Generate the hardware configuration files and copy the configuration files to the right place in PetaLinux. <pre> $ cd /opt/petalinux-v1.3-final-full/hardware/user-platforms/YourProject $ petalinux-copy-autoconfig </pre> Launch the Linux kernel configuration menu and do some configuration if needed. <pre> $ petalinux-config-kernel </pre> Launch the user applications and system settings configuration menu. <pre> $ petalinux-config-apps </pre> == Build PetaLinux == This step take some time <pre> $ cd $PETALINUX/software/petalinux-dist $ make </pre> The compilation log stores in ''build.log'' file in the ''petalinux-dist/'' directory. == Run On Board == Run XMD by typing ''xmd'' in the terminal. Downlad the hardware bitstream to the fpga and connect to the board. <pre> XMD% fpga -f /opt/petalinux-v1.3-final-full/hardware/user-platforms/YourProject/implementation/download.bit XMD% connect mb mdm -debugdevice devicenr # </pre> Check the value of ''Instruction Cache Base Address'', i.e.: * Instruction Cache Base Address.....0xb0000000 Download PetaLinux binary image to board at the instruction cache base address, set program counter to that location and tell the board to start/continue. <pre> XMD% dow -data /opt/petalinux-v1.3-final-full/software/petalinux-dist/images/linux.bin 0xb0000000 XMD% rwr pc 0xb0000000 XMD% con </pre> Connect to UART with settings 115200 8-N-1. Log in as "root" with password "root". Have fun! == Digilent Atlys == When using XMD on the Atlys, it is necessary to provide extra statements to communicate with the hardware: -cable type xilinx_plugin modulename digilent_plugin i.e. fpga -f download.bit -cable type xilinx_plugin modulename digilent_plugin connect mb mdm -cable type xilinx_plugin modulename digilent_plugin From here you just do as usual, i.e. dow -data linux.bin 0xb0000000 <...> == ISE DS Version 13.1 == === Ethernet MAC Address === The MAC address is randomized by default. Use the PetaLinux System Configuration Menu to specify the new MAC address. $ petalinux-config-apps System Settings ---> Network Addresses Untick "Randomise MAC address" and enter appropriate MAC address in the next field. Exit and save. Rebuild U-boot and the images within PetaLinux: [petalinux/software/petalinux-dist]$ make u-boot image New in platform configuration $ petalinux-platform-config --update [http://www.petalogix.com/resources/documentation/petalinux/userguide/Bootloaders/UBoot/UBMacStorage PetaLinux User Guide - Updating Ethernet MAC Address] [[Category:Embedded]] d544fbe6550c9a6c64dd24636fe5cf5b5dcb4669 0 362 1598 2011-06-22T12:53:41Z Nfyku 4 Created page with 'Embedded Systems Tools Reference Manual XMD user commands at p. 147 through p. 152 terminal -- Communicate with mdm UART through JTAG. - see p. 151 for details. verbose -- T…' wikitext text/x-wiki Embedded Systems Tools Reference Manual XMD user commands at p. 147 through p. 152 terminal -- Communicate with mdm UART through JTAG. - see p. 151 for details. verbose -- Turns verbose mode on/off, in verbose mode xmd prints debug information. [[Category:Embedded Linux]] 9409eff001be925d50e9dbdc9d8a9d29558de99e 1605 1598 2011-06-22T13:04:49Z Nfyku 4 wikitext text/x-wiki Embedded Systems Tools Reference Manual XMD user commands at p. 147 through p. 152 terminal -- Communicate with mdm UART through JTAG. - see p. 151 for details. verbose -- Turns verbose mode on/off, in verbose mode xmd prints debug information. [[Category:Embedded]] 99b63a5ef0a6f3e14f505ca5b6b3908a9edbff3b 0 363 1599 2011-06-22T12:54:07Z Nfyku 4 Created page with '==Making the driver work== Download and extract [http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=snapshot;h=HEAD;sf=tgz libusb-driver]. <pre> $ cd /path/to/driver/ $ m…' wikitext text/x-wiki ==Making the driver work== Download and extract [http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=snapshot;h=HEAD;sf=tgz libusb-driver]. <pre> $ cd /path/to/driver/ $ make $ LD_PRELOAD=/path/to/driver/libusb-driver.so </pre> Pull out the usb cable and put it back in. <pre> $ /sbin/lsusb </pre> Make sure the cable has got the ID 03fd:0008, if not - consult [http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=blob_plain;f=README;hb=HEAD README]. ==Other== Make sure you have ran <pre> $ source /opt/Xilinx/12.3/ISE_DS/settings32.sh </pre> ==Sources== [http://rmdir.de/~michael/xilinx/ 1] [http://www.linuxquestions.org/questions/puppy-71/need-kernel-headers-to-install-fxload-no-linux-directory-741332/ 2] [http://forums.xilinx.com/t5/Installation-and-Licensing/How-to-install-Xilinx-ISE-and-USB-drivers-CentOS-5/td-p/54250/page/2 3] [http://www.spinics.net/lists/hotplug/msg03356.html 4] [http://www.xilinx.com/support/answers/29310.htm 5] [http://archive.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2007/03/msg00101.html 6] [[Category:Embedded]] d530825d5d9c52ca6c7a813b847d9bf852780387 0 364 1600 2011-06-22T12:54:28Z Nfyku 4 Created page with '== General compiling == the error 'line 1: syntax error: unexpected "("' usually means that I have tried to make a custom user application on 'raven' from its directory, and sinc…' wikitext text/x-wiki == General compiling == the error 'line 1: syntax error: unexpected "("' usually means that I have tried to make a custom user application on 'raven' from its directory, and since the Makefile inherits some stuff from petalinux Makefile, it gets built for x86 and not microblaze. == Bus Functional Models == Copied bfm files to EDK directory, then ran the following [localhost] /opt/Xilinx/12.3/ISE_DS > xilbfc -check xilbfc: error while loading shared libraries: libPortability.so: cannot open shared object file: No such file or directory Did some hacks: [localhost] /opt/Xilinx/12.3/ISE_DS > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$XILINX/lib/lin [localhost] /opt/Xilinx/12.3/ISE_DS > xilbfc ERROR:EDK - Unable to open the log file "xilbfc.log" Try to sudo xilbfc -check gives the same library error as before, might be something wrong with the install? [[Category:Embedded]] 3b9929c674c1033493e35c081a8df4fa41ea18e6 0 365 1601 2011-06-22T12:58:16Z Nfyku 4 Created page with '== CGI scripts == $ cd /opt/petalinux-v1.3-final-full/software/petalinux-dist $ petalinux-config-apps Scroll to PetaLogix Demo Applications and enter. Uncheck uWeb and exit. Sc…' wikitext text/x-wiki == CGI scripts == $ cd /opt/petalinux-v1.3-final-full/software/petalinux-dist $ petalinux-config-apps Scroll to PetaLogix Demo Applications and enter. Uncheck uWeb and exit. Scroll to BusyBox->Networking Utilities and make sure httpd is checked. Exit and make the Petalinux image. The server files is now located in '/home/httpd'. CGI scripts should go in cgi-bin directory and chmoded to +x. [http://www.tidsreise.com/filer/simple-webinterface.zip Here] is a simple script used to read and write to memory using 'devmem'. == Interface == [http://cssbeauty.com/skillshare/discussion/3304/styled-checkbox-cross-browser-solution/] == Troubleshooting == First I tried to modify the default page source files (i.e. petalinux.page) but found out that the whole page is some binary, so the [http://www.workware.net.au/Workware/uWeb.html uWeb] API is needed. Then I set out to install php. * Attempt 1 Follow [http://www.menie.org/georges/uClinux/boa-php.html the guide] by Georges Ménie (excluding boa). I downloaded [http://museum.php.net/php4/php-4.3.10.tar.gz php-4.3.10] and applied Georges' patch. Did not compile, so I did some desperate fiddling and came to short. * Attempt 2 **Downloaded the latest [http://www.php.net/get/php-5.3.6.tar.gz/from/a/mirror php-5.3.6]. **Extracted to '/opt/petalinux-v1.3-final-full/software/petalinux-dist/user' to a folder 'php'. **Edit /opt/petalinux-v1.3-final-full/software/petalinux-dist/user/Makefile: dir_$(CONFIG_USER_PHP_PHP) += php **Edit /opt/petalinux-v1.3-final-full/software/petalinux-dist/config/Kconfig config USER_PHP_PHP bool "php" help Testing php support This adds the php application to the petalinux-config-apps ui where we can select it to be compiled to the petalinux image. **Enter php directory in user catalog ./configure --disable-all **Edit /opt/petalinux-v1.3-final-full/software/petalinux-dist/user/php/Makefile CC = /opt/petalinux-v1.3-final-full/tools/linux-i386/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/bin/gcc When compiling the petalinux image, I get no errors in the compile step of php, but get a romfs error during the install step. I believe it has something to do with the large filesize of the php binary or some problem with the Makefile. == References == #[https://docs.blackfin.uclinux.org/doku.php?id=adding_user_applications uClinux - Adding user applications] #[http://www.menie.org/georges/uClinux/boa-php.html BOA + PHP for uClinux] #[http://oldwiki.openwrt.org/OpenWrtDocs(2f)httpd_CGI_scripts.html CGI html form example 1] #[http://www.jmarshall.com/easy/cgi/cgi_footnotes.html#security CGI security, to be read] #[http://www.ooblick.com/text/sh/ Bourne shell reference] #[http://foxlx.acmesystems.it/?id=165 Les] [[Category:Embedded]] b8bc6eda507551500b149368c5f86fc77fbf9ece 0 366 1602 2011-06-22T12:59:54Z Nfyku 4 Created page with '== notes == Sysfs exports information about devices and drivers from the kernel device model to userspace. Gpio-sysfs is the prefered method for accessing gpio from userspace. It…' wikitext text/x-wiki == notes == Sysfs exports information about devices and drivers from the kernel device model to userspace. Gpio-sysfs is the prefered method for accessing gpio from userspace. It deals with one pin at a time and works in means of reading and writing to files for control. The control files for each gpio chip is contained within '/sys/class/gpio/' ~ # ls /sys/class/gpio/ export gpiochip231 gpiochip235 gpiochip240 gpiochip248 unexport To begin with there is only two files 'export' and 'unexport' and a folder for each gpio, each gpio has an ID number. In each folder there are files that contains information about the chip: ~ # ls /sys/class/gpio/gpiochip231/ base label ngpio subsystem uevent *'base' contains the ID of the chip, i.e. for gpiochip231, the ID is 231 ~ # cat /sys/class/gpio/gpiochip231/base 231 *'label' contains the address (so that you are able to identify which gpio you are dealing with) ~ # cat /sys/class/gpio/gpiochip231/label /plb@0/gpio@81400000 *'ngpio' contains the number of gpio pins available In order to get access to a GPIO pin it is necessary to export it using the export file: echo NN > /sys/class/gpio/export Where NN is the base of the GPIO chip plus the pin number, i.e. for pin0 of gpiochip231 NN=231, for pin1 NN=232, etc. An example: echo 231 > /sys/class/gpio/export echo 232 > /sys/class/gpio/export This gives access to pin0 and pin1. When a pin is exported, a folder is created: '/sys/class/gpio/gpioNN'. Within such a folder you have the control files for the pin, 'direction' and 'value' ~ # ls /sys/class/gpio/gpio231/ direction subsystem uevent value Example, setting direction of pin0 as output: echo out > /sys/class/gpio/gpio231/direction Possible commands for direction: high Set GPIO to an output with a starting value of 1 low Set GPIO to an output with a starting value of 0 out Same as low in Set GPIO to an input Example, setting value of a pin0 to 1, then reading the value: echo 1 > /sys/class/gpio/gpio231/value cat /sys/class/gpio/gpio231/value 1 Current design: sig phys NN TDI -> pin6 -> 231 TMS -> pin4 -> 232 TDO -> pin3 -> 233 TCK -> pin1 -> 234 == References == *[http://www.labbookpages.co.uk/electronics/avrs/toolChain.html AVR Hex to SVF] *[http://dangerousprototypes.com/tag/xsvf-player/ XSVF stuff to look in to] *[http://dangerousprototypes.com/docs/Bus_Pirate Bus pirate] *[http://code.google.com/p/the-bus-pirate/updates/list some bus pirate files] *[http://code.google.com/p/the-bus-pirate/downloads/detail?name=BPv3.XSVFplayer.v1.1.zip Bus pirate xvsf player stuff] *[http://www2.embedded-projects.net/index.php?page_id=221 Even some more about xsvf] *[http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=57510&highlight=spi+ngw100] *[https://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:simple-gpio] *[http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/GPIO] *[http://xilinx.eefocus.com/wall/index.php?act=read&id=1605] *[http://hackaday.com/2008/12/01/bus-pirate-firmware-update-v0c-jtag-and-more/] *[http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/Newbie/Detailed_IO_Tutorial] [[Category:Embedded]] ec02645b4edba1607422d2417c0df7cc46e2ef23 6 367 1607 2011-06-27T12:19:38Z Jli051 54 Talk given at Fysikermøtet 2011, University of Oslo wikitext text/x-wiki Talk given at Fysikermøtet 2011, University of Oslo 57a38c366e006c13622845ab54fa5a9274c1e2a9 0 3 1609 1334 2011-08-12T12:43:30Z Nfyku 4 Updated to firmware version 57 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behavior of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] eb224b2bbe4079bb070b8c3104f7eeb651c687c2 1611 1609 2011-08-15T08:34:45Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[http://folk.uib.no/st09909/HIB_selectMAP_rapport/Sluttrapport/SelectMAP_Kernel_Module_-_Sluttrapport.pdf SelectMAP driver (Report be HIB students, in norwegian)] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 42a414e1cb7fe56f095eb767d253faa5b400f9c2 1613 1611 2011-08-16T06:59:38Z Nfyku 4 Lastet opp HiB-rapport til wikihost wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] c2faf1b201c9058c5e8e904e691cd64d4e45ddec 1614 1613 2011-08-16T07:03:40Z Nfyku 4 Lastet opp HiB-rapport til wikihost wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[File:SelectMAP_Kernel_Module|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 67a809a1e25a5d905e8d47b1681d59e5f1046948 0 242 1610 1266 2011-08-12T12:56:41Z Nfyku 4 Changed from L0 to L1A trigger timeout wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L1 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L1A trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L1 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Enable RoI decoding. Default=0 |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x13 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not Used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3014 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3015 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3050 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3052 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3053 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} f40bfc5d0445b69bec444085a996d2b3e362342c 0 21 1612 1534 2011-08-15T12:12:24Z Zzh026 61 wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Zhou * Postdoctors: Trygve * Researcher: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332 (55588306) * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 02.05. - 06.05.11: IRTG medical physics, Bergen * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. 14252aaeedf891f44f3bb039627986481d6e3287 1615 1612 2011-08-18T06:45:58Z Dfe002 7 /* Meetings and conferences */ wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Njål, Stian, Kristian, Eivind, Arild, Zhou * Postdoctors: Trygve * Researcher: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: [http://www.uib.no/personer/Dominik.Fehlker Dominik], Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332 (55588306) * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. c1218951dfa619782afbcda5f55b033d5b8275da 0 196 1616 1226 2011-08-18T06:47:14Z Dfe002 7 wikitext text/x-wiki Here you can put the equipment, components, stuff that you will need for your project. During the meetings we can then compile the priorities from the list and see where we find money for it. ==XYZ-table setup== b66aa237d641a3f5c0ed9f8fe4a542b4c83d1e02 0 111 1617 1394 2011-08-18T06:55:59Z Dfe002 7 added xy stages wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Number !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |2 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |1 |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |1 |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |4 |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |2 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |1 |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |1 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, 5 Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf Users manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} = XY stages = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manual !Software !default values |- |2 x Zaber T-LSM200B |Motorized Stage, 200 mm travel, RS-232 plus manual control |[http://www.zaber.com/wiki/Manuals/T-LSM wiki], [http://www.zaber.com/documents/T-LSM-manual.pdf pdf] |[http://www.zaber.com/wiki/Software software] |[http://www.zaber.com/support/?tab=Device%20ids#tabs def. val.] |} 1c61ca5f563d9c71d8b3e834d590021ac7fff31b 0 111 1618 1617 2011-08-18T07:01:10Z Dfe002 7 /* NIM devices */ added Caen HV PSU wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Number !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |2 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |1 |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |1 |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |4 |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |2 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |1 |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |1 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, 5 Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] |CERN |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf manual] | |- |Caen N1471A |2 Ch programmable High Voltage PSU, 5.5 kV / 300 µA |[http://www.caen.it/servlet/checkCaenManualFile?Id=7746 manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} = XY stages = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manual !Software !default values |- |2 x Zaber T-LSM200B |Motorized Stage, 200 mm travel, RS-232 plus manual control |[http://www.zaber.com/wiki/Manuals/T-LSM wiki], [http://www.zaber.com/documents/T-LSM-manual.pdf pdf] |[http://www.zaber.com/wiki/Software software] |[http://www.zaber.com/support/?tab=Device%20ids#tabs def. val.] |} 94d27ad7ab1bd456f31c5724e6f6a8319a3200f8 1619 1618 2011-08-18T07:01:28Z Dfe002 7 /* VME devices */ wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Number !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |2 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |1 |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |1 |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |4 |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |2 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |1 |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |1 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, 5 Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] | |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf manual] | |- |Caen N1471A |2 Ch programmable High Voltage PSU, 5.5 kV / 300 µA |[http://www.caen.it/servlet/checkCaenManualFile?Id=7746 manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} = XY stages = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manual !Software !default values |- |2 x Zaber T-LSM200B |Motorized Stage, 200 mm travel, RS-232 plus manual control |[http://www.zaber.com/wiki/Manuals/T-LSM wiki], [http://www.zaber.com/documents/T-LSM-manual.pdf pdf] |[http://www.zaber.com/wiki/Software software] |[http://www.zaber.com/support/?tab=Device%20ids#tabs def. val.] |} cbc6d9b5ef5e8f14ce6357cb25c929b3928ef82a 0 278 1620 1185 2011-08-23T14:37:27Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] bff63f310d3778bde97acb992c7cef319b5332f4 0 202 1621 1297 2011-08-29T12:25:22Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [[http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]] * [[http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [[http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]] * [[http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets]] * [[http://www.semi1source.com/glossary/ Semiconductor Glossary ] === Prosessteknologi === [[http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbors]] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [[http://www.aimspice.com/download.html Download a free student version]] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV]] [[Category:Mikroelektronikk]] c3b6a1f0f639b14d92929734d62d4286247b23ed 1622 1621 2011-08-29T12:26:27Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Artikler === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] ffc82af6642cfa64a27b636cdc52d47580a42fb7 1623 1622 2011-08-29T12:37:39Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[File:p-n_junctions.pdf]] === Prosessteknologi === [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 9cbcf47be8fdc498deeb8a4f505bfaeae9df4d7d 1625 1623 2011-08-29T12:39:53Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[File:p-n_junctions.pdf Elementary Physics of P-N Junctions]] === Prosessteknologi === [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 8baa595a8d78d4f971341144d84f69a7400c7f2b 1626 1625 2011-08-29T12:49:53Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf|Elementary Physics of P-N Junctions]] === Prosessteknologi === [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 8becec0973e2dcfb983832f35be1a4def7808c56 1632 1626 2011-09-21T09:15:55Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf|Elementary Physics of P-N Junctions]] === Prosessteknologi === [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 95208a01dcb147b50870bbe9d65cafa2ce53b85f 1663 1632 2011-09-26T08:13:44Z Nfyku 4 Added link to "The Asymptotic Bode Diagram: Derivation of Approximations" wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf|Elementary Physics of P-N Junctions]] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html|The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 5dbe884b90f2a71ef412e114235eee17cf8e3bcf 6 368 1624 2011-08-29T12:39:01Z Nfyku 4 Elementary Physics of P-N Junctions wikitext text/x-wiki Elementary Physics of P-N Junctions 9af1dae57d7cc2e7590678c411ba3d3234473d48 0 3 1627 1614 2011-08-30T08:54:15Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] fdcc64154a0a9aae3c7b55127d1153cc2fe86521 6 369 1628 2011-08-30T08:54:27Z Nfyku 4 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 1 1629 1457 2011-09-21T09:09:44Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] * [[DAMARA]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 2179b4e43f98488512b694a4fcf80114f2be5952 1630 1629 2011-09-21T09:09:58Z Nfyku 4 wikitext text/x-wiki <big>'''Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] * [[DAMARA]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 07b0abd4535ab46f21406791beee90f453cfdb78 0 370 1631 2011-09-21T09:11:32Z Nfyku 4 Created page with '[[Applied Planetary Radio Astronomy]]' wikitext text/x-wiki [[Applied Planetary Radio Astronomy]] 42df9bd75d5f9e2c1bc6f3bab35209b15e5ca735 1634 1631 2011-09-21T20:32:04Z Gge002 52 wikitext text/x-wiki [[Applied Radio Astronomy]] 2adce9c2ca41d34374896db266b4992770ec2443 1635 1634 2011-09-21T20:32:22Z Gge002 52 wikitext text/x-wiki [[Applied Planetary Radio Astronomy]] 42df9bd75d5f9e2c1bc6f3bab35209b15e5ca735 1667 1635 2011-09-28T06:32:55Z Nfyku 4 wikitext text/x-wiki * [[Applied Planetary Radio Astronomy]] * [[Phys117_-_PET_project|PET detector]] 503984dcce1ac5ef498ccbfe42b55e57748a6811 0 371 1633 2011-09-21T20:27:48Z Gge002 52 Created page with '= Jovian Radio Storms = == Project Outline == == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation' wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation 68b01dd86fd724104ffee2028329a52ed46dd3f4 1636 1633 2011-09-21T21:05:20Z Gge002 52 some initial hypothethic chaptering wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennas - Construction and Theory = 7f29523adf4c0e9ab6d653df437b13eb14adf236 1638 1636 2011-09-21T21:18:48Z Gge002 52 wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennas - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] 6dd4dedb35d4fe8a1d5b4e6ad10cc17c8a9cd227 1639 1638 2011-09-22T06:33:18Z Gge002 52 added project outline wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == The project is suitable for 1-2 practically oriented students with broad interests, who do not mind “getting their hands dirty” every now and then, in addition to the time spent in front of the PC. #Contact persons – Georgi Genov, Kjetil Ullaland, Nikolai Østgaard, Kjell Aarsnes #Aim To learn basic radio astronomy, to modify an existing radio telescope amplifier (RTA), to build the telescope’s antennas and to establish observational procedures. #Tasks #*Modifying the existing RTA for automatic sweep of the frequency range; #*Building the electronics required to establish the computer communication; #*Building and set up of the antennas of the radio telescope; #*Developing a simple software for data acquisition and preliminary data analysis; #*Performing tests and developing observational procedures. #Benefits – learn basic radio astronomy; get hands-on experience with applied electronics, data acquisition and data analysis, development of software for scientific purposes. #Background Two types of radio noise emitted by Jupiter have been detected – synchrotron and cyclotron. The latter is strong enough to be detected by small antennas on Earth’s surface. Charged particles spiraling around Jupiter’s magnetic field lines near both magnetic poles (top figure) produce this cyclotron radiation. These shortwave signals are often referred to as DAM, since they fall in the decameter wavelength range. At these higher latitudes, where Jupiter’s magnetic field reaches as far out as Io, its field lines sweep rapidly past the ions and electrons shed into Io’s torus. This induces DAM radiation along the surface of the cyclotron cone (given in magenta in the middle figure). Jupiter’s DAM frequency reaches a maximum of 39.5 MHz near Jupiter’s cloud tops. At twice Jupiter’s radius the frequency is 3 MHz. Intermediate frequencies are created between these two extreme distances. Jupiter radiates two distinctive types of radio signatures in the DAM frequency range: *L-bursts –long duration static sounding like the swoosh of the waves; *S-bursts – short duration static resembling the crackling of a campfire. DAM radiation originates from at least 3 sources (A, B and C) that are fixed with respect to the planet’s rotating magnetic field. These sources are observed at around 20 MHz. They fall largely around one hemisphere (bottom figure). Source A is more than twice more likely to emit than either B or C. Jupiter’s magnetic storms depend on a combination of Io’s orbital position and the inclination of the respective radio source with respect to Earth. == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennas - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] 72f14db32d9339e5542147c5f7009c0b2232ddd4 1643 1639 2011-09-22T06:47:49Z Gge002 52 added pics to project outline wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == [[File:Jupiter1.jpg|thumb|alt=Charged partical trajectory in Jupiter's magnetic field|Charged partical trajectory in Jupiter's magnetic field]] [[File:Jupiter2.jpg|thumb|alt=Origin of the different frequency emissions in Jupiter's magnetic field|Origin of the different frequency emissions in Jupiter's magnetic field]] [[File:Jupiter3.jpg|thumb|alt=Jupiter's A-, B- and C type radio burst|Jupiter's A-, B- and C type radio burst]] The project is suitable for 1-2 practically oriented students with broad interests, who do not mind “getting their hands dirty” every now and then, in addition to the time spent in front of the PC. #Contact persons – Georgi Genov, Kjetil Ullaland, Nikolai Østgaard, Kjell Aarsnes #Aim To learn basic radio astronomy, to modify an existing radio telescope amplifier (RTA), to build the telescope’s antennas and to establish observational procedures. #Tasks #*Modifying the existing RTA for automatic sweep of the frequency range; #*Building the electronics required to establish the computer communication; #*Building and set up of the antennas of the radio telescope; #*Developing a simple software for data acquisition and preliminary data analysis; #*Performing tests and developing observational procedures. #Benefits – learn basic radio astronomy; get hands-on experience with applied electronics, data acquisition and data analysis, development of software for scientific purposes. #Background Two types of radio noise emitted by Jupiter have been detected – synchrotron and cyclotron. The latter is strong enough to be detected by small antennas on Earth’s surface. Charged particles spiraling around Jupiter’s magnetic field lines near both magnetic poles (top figure) produce this cyclotron radiation. These shortwave signals are often referred to as DAM, since they fall in the decameter wavelength range. At these higher latitudes, where Jupiter’s magnetic field reaches as far out as Io, its field lines sweep rapidly past the ions and electrons shed into Io’s torus. This induces DAM radiation along the surface of the cyclotron cone (given in magenta in the middle figure). Jupiter’s DAM frequency reaches a maximum of 39.5 MHz near Jupiter’s cloud tops. At twice Jupiter’s radius the frequency is 3 MHz. Intermediate frequencies are created between these two extreme distances. Jupiter radiates two distinctive types of radio signatures in the DAM frequency range: *L-bursts –long duration static sounding like the swoosh of the waves; *S-bursts – short duration static resembling the crackling of a campfire. DAM radiation originates from at least 3 sources (A, B and C) that are fixed with respect to the planet’s rotating magnetic field. These sources are observed at around 20 MHz. They fall largely around one hemisphere (bottom figure). Source A is more than twice more likely to emit than either B or C. Jupiter’s magnetic storms depend on a combination of Io’s orbital position and the inclination of the respective radio source with respect to Earth. == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennas - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] 063a1dfdb3dc7925ddab0ddaca14c17d6010bbf4 1644 1643 2011-09-22T06:50:27Z Gge002 52 wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == [[File:Jupiter1.jpg|thumb|alt=Charged partical trajectory in Jupiter's magnetic field|Charged partical trajectory in Jupiter's magnetic field]] [[File:Jupiter2.jpg|thumb|alt=Origin of the different frequency emissions in Jupiter's magnetic field|Origin of the different frequency emissions in Jupiter's magnetic field]] [[File:Jupiter3.jpg|thumb|alt=Jupiter's A-, B- and C type radio burst|Jupiter's A-, B- and C type radio burst]] The project is suitable for 1-2 practically oriented students with broad interests, who do not mind “getting their hands dirty” every now and then, in addition to the time spent in front of the PC. #Contact persons – Georgi Genov, Kjetil Ullaland, Nikolai Østgaard, Kjell Aarsnes #Aim - To learn basic radio astronomy, to modify an existing radio telescope amplifier (RTA), to build the telescope’s antennas and to establish observational procedures. #Tasks #*Modifying the existing RTA for automatic sweep of the frequency range; #*Building the electronics required to establish the computer communication; #*Building and set up of the antennas of the radio telescope; #*Developing a simple software for data acquisition and preliminary data analysis; #*Performing tests and developing observational procedures. #Benefits – learn basic radio astronomy; get hands-on experience with applied electronics, data acquisition and data analysis, development of software for scientific purposes. #Background Two types of radio noise emitted by Jupiter have been detected – synchrotron and cyclotron. The latter is strong enough to be detected by small antennas on Earth’s surface. Charged particles spiraling around Jupiter’s magnetic field lines near both magnetic poles (top figure) produce this cyclotron radiation. These shortwave signals are often referred to as DAM, since they fall in the decameter wavelength range. At these higher latitudes, where Jupiter’s magnetic field reaches as far out as Io, its field lines sweep rapidly past the ions and electrons shed into Io’s torus. This induces DAM radiation along the surface of the cyclotron cone (given in magenta in the middle figure). Jupiter’s DAM frequency reaches a maximum of 39.5 MHz near Jupiter’s cloud tops. At twice Jupiter’s radius the frequency is 3 MHz. Intermediate frequencies are created between these two extreme distances. Jupiter radiates two distinctive types of radio signatures in the DAM frequency range: *L-bursts –long duration static sounding like the swoosh of the waves; *S-bursts – short duration static resembling the crackling of a campfire. DAM radiation originates from at least 3 sources (A, B and C) that are fixed with respect to the planet’s rotating magnetic field. These sources are observed at around 20 MHz. They fall largely around one hemisphere (bottom figure). Source A is more than twice more likely to emit than either B or C. Jupiter’s magnetic storms depend on a combination of Io’s orbital position and the inclination of the respective radio source with respect to Earth. == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennas - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] ec034eeed7d615042fb9302498d494d5b71690c9 1645 1644 2011-09-22T11:44:25Z Gge002 52 wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == [[File:Jupiter1.jpg|thumb|alt=Charged partical trajectory in Jupiter's magnetic field|Charged partical trajectory in Jupiter's magnetic field]] [[File:Jupiter2.jpg|thumb|alt=Origin of the different frequency emissions in Jupiter's magnetic field|Origin of the different frequency emissions in Jupiter's magnetic field]] [[File:Jupiter3.jpg|thumb|alt=Jupiter's A-, B- and C type radio burst|Jupiter's A-, B- and C type radio burst]] The project is suitable for 1-2 practically oriented students with broad interests, who do not mind “getting their hands dirty” every now and then, in addition to the time spent in front of the PC. #Contact persons – Georgi Genov, Kjetil Ullaland, Nikolai Østgaard, Kjell Aarsnes #Aim - To learn basic radio astronomy, to modify an existing radio telescope amplifier (RTA), to build the telescope’s antennas and to establish observational procedures. #Tasks #*Modifying the existing RTA for automatic sweep of the frequency range; #*Building the electronics required to establish the computer communication; #*Building and set up of the antennas of the radio telescope; #*Developing a simple software for data acquisition and preliminary data analysis; #*Performing tests and developing observational procedures. #Benefits – learn basic radio astronomy; get hands-on experience with applied electronics, data acquisition and data analysis, development of software for scientific purposes. #Background Two types of radio noise emitted by Jupiter have been detected – synchrotron and cyclotron. The latter is strong enough to be detected by small antennas on Earth’s surface. Charged particles spiraling around Jupiter’s magnetic field lines near both magnetic poles (top figure) produce this cyclotron radiation. These shortwave signals are often referred to as DAM, since they fall in the decameter wavelength range. At these higher latitudes, where Jupiter’s magnetic field reaches as far out as Io, its field lines sweep rapidly past the ions and electrons shed into Io’s torus. This induces DAM radiation along the surface of the cyclotron cone (given in magenta in the middle figure). Jupiter’s DAM frequency reaches a maximum of 39.5 MHz near Jupiter’s cloud tops. At twice Jupiter’s radius the frequency is 3 MHz. Intermediate frequencies are created between these two extreme distances. Jupiter radiates two distinctive types of radio signatures in the DAM frequency range: *L-bursts –long duration static sounding like the swoosh of the waves; *S-bursts – short duration static resembling the crackling of a campfire. DAM radiation originates from at least 3 sources (A, B and C) that are fixed with respect to the planet’s rotating magnetic field. These sources are observed at around 20 MHz. They fall largely around one hemisphere (bottom figure). Source A is more than twice more likely to emit than either B or C. Jupiter’s magnetic storms depend on a combination of Io’s orbital position and the inclination of the respective radio source with respect to Earth. == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennae - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] = Books = == The Radio Sky and How to Observe It - by Jeff Lashley == [[:File:Ch0.pdf|Preface and Table of contents]] [[:File:Ch1.pdf|Chapter 1 - The Radio Sun]] [[:File:Ch2.pdf|Chapter 2 - Jupiter]] [[:File:Ch3.pdf|Chapter 3 - Meteors and Meteor Streams]] [[:File:Ch4.pdf|Chapter 4 - Beyond the Solar System]] [[:File:Ch5.pdf|Chapter 5 - Antennae]] [[:File:Ch6.pdf|Chapter 6 - Setting Up a Radio Astronomy Station]] [[:File:Ch7.pdf|Chapter 7 - Radio Hardware Theory]] [[:File:Ch8.pdf|Chapter 8 - Introduction to RF Electronics]] [[:File:Ch9.pdf|Chapter 9 - Building a Very Low Frequency Solar Flare Monitor]] [[:File:Ch10.pdf|Chapter 10 - Microwave Radio Telescope Projects]] [[:File:Ch11.pdf|Chapter 11 - Building a Jupiter Radio Telescope]] [[:File:Ch12.pdf|Chapter 12 - Building a Broad Band Solar Radio Telescope]] [[:File:Ch13.pdf|Chapter 13 - Data Logging and Data Processing]] [[:File:AppA.pdf|Appendices - Formulae; Bibliography; Suppliers, Groups, and Societies; Glossary]] = Articles = [[Category:Added The Radio Sky and How to Observe It - by Jeff Lashley]] 854aa1547f817cf05adb1899b027afe5df75942a 1661 1645 2011-09-22T12:02:53Z Gge002 52 Added The Radio Sky and How to Observe It - by Jeff Lashley wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == [[File:Jupiter1.jpg|thumb|alt=Charged partical trajectory in Jupiter's magnetic field|Charged partical trajectory in Jupiter's magnetic field]] [[File:Jupiter2.jpg|thumb|alt=Origin of the different frequency emissions in Jupiter's magnetic field|Origin of the different frequency emissions in Jupiter's magnetic field]] [[File:Jupiter3.jpg|thumb|alt=Jupiter's A-, B- and C type radio burst|Jupiter's A-, B- and C type radio burst]] The project is suitable for 1-2 practically oriented students with broad interests, who do not mind “getting their hands dirty” every now and then, in addition to the time spent in front of the PC. #Contact persons – Georgi Genov, Kjetil Ullaland, Nikolai Østgaard, Kjell Aarsnes #Aim - To learn basic radio astronomy, to modify an existing radio telescope amplifier (RTA), to build the telescope’s antennas and to establish observational procedures. #Tasks #*Modifying the existing RTA for automatic sweep of the frequency range; #*Building the electronics required to establish the computer communication; #*Building and set up of the antennas of the radio telescope; #*Developing a simple software for data acquisition and preliminary data analysis; #*Performing tests and developing observational procedures. #Benefits – learn basic radio astronomy; get hands-on experience with applied electronics, data acquisition and data analysis, development of software for scientific purposes. #Background Two types of radio noise emitted by Jupiter have been detected – synchrotron and cyclotron. The latter is strong enough to be detected by small antennas on Earth’s surface. Charged particles spiraling around Jupiter’s magnetic field lines near both magnetic poles (top figure) produce this cyclotron radiation. These shortwave signals are often referred to as DAM, since they fall in the decameter wavelength range. At these higher latitudes, where Jupiter’s magnetic field reaches as far out as Io, its field lines sweep rapidly past the ions and electrons shed into Io’s torus. This induces DAM radiation along the surface of the cyclotron cone (given in magenta in the middle figure). Jupiter’s DAM frequency reaches a maximum of 39.5 MHz near Jupiter’s cloud tops. At twice Jupiter’s radius the frequency is 3 MHz. Intermediate frequencies are created between these two extreme distances. Jupiter radiates two distinctive types of radio signatures in the DAM frequency range: *L-bursts –long duration static sounding like the swoosh of the waves; *S-bursts – short duration static resembling the crackling of a campfire. DAM radiation originates from at least 3 sources (A, B and C) that are fixed with respect to the planet’s rotating magnetic field. These sources are observed at around 20 MHz. They fall largely around one hemisphere (bottom figure). Source A is more than twice more likely to emit than either B or C. Jupiter’s magnetic storms depend on a combination of Io’s orbital position and the inclination of the respective radio source with respect to Earth. == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennae - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] = Books = == The Radio Sky and How to Observe It - by Jeff Lashley == [[:File:Ch0.pdf|Preface and Table of contents]] [[:File:Ch1.pdf|Chapter 1 - The Radio Sun]] [[:File:Ch2.pdf|Chapter 2 - Jupiter]] [[:File:Ch3.pdf|Chapter 3 - Meteors and Meteor Streams]] [[:File:Ch4.pdf|Chapter 4 - Beyond the Solar System]] [[:File:Ch5.pdf|Chapter 5 - Antennae]] [[:File:Ch6.pdf|Chapter 6 - Setting Up a Radio Astronomy Station]] [[:File:Ch7.pdf|Chapter 7 - Radio Hardware Theory]] [[:File:Ch8.pdf|Chapter 8 - Introduction to RF Electronics]] [[:File:Ch9.pdf|Chapter 9 - Building a Very Low Frequency Solar Flare Monitor]] [[:File:Ch10.pdf|Chapter 10 - Microwave Radio Telescope Projects]] [[:File:Ch11.pdf|Chapter 11 - Building a Jupiter Radio Telescope]] [[:File:Ch12.pdf|Chapter 12 - Building a Broad Band Solar Radio Telescope]] [[:File:Ch13.pdf|Chapter 13 - Data Logging and Data Processing]] [[:File:AppA.pdf|Appendices - Formulae; Bibliography; Suppliers, Groups, and Societies; Glossary]] = Articles = 990611bfe489f8bd8491347cb6c8c837f8186e69 1662 1661 2011-09-22T17:31:21Z Gge002 52 radio freq bands added wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == [[File:Jupiter1.jpg|thumb|alt=Charged partical trajectory in Jupiter's magnetic field|Charged partical trajectory in Jupiter's magnetic field]] [[File:Jupiter2.jpg|thumb|alt=Origin of the different frequency emissions in Jupiter's magnetic field|Origin of the different frequency emissions in Jupiter's magnetic field]] [[File:Jupiter3.jpg|thumb|alt=Jupiter's A-, B- and C type radio burst|Jupiter's A-, B- and C type radio burst]] The project is suitable for 1-2 practically oriented students with broad interests, who do not mind “getting their hands dirty” every now and then, in addition to the time spent in front of the PC. #Contact persons – Georgi Genov, Kjetil Ullaland, Nikolai Østgaard, Kjell Aarsnes #Aim - To learn basic radio astronomy, to modify an existing radio telescope amplifier (RTA), to build the telescope’s antennas and to establish observational procedures. #Tasks #*Modifying the existing RTA for automatic sweep of the frequency range; #*Building the electronics required to establish the computer communication; #*Building and set up of the antennas of the radio telescope; #*Developing a simple software for data acquisition and preliminary data analysis; #*Performing tests and developing observational procedures. #Benefits – learn basic radio astronomy; get hands-on experience with applied electronics, data acquisition and data analysis, development of software for scientific purposes. #Background Two types of radio noise emitted by Jupiter have been detected – synchrotron and cyclotron. The latter is strong enough to be detected by small antennas on Earth’s surface. Charged particles spiraling around Jupiter’s magnetic field lines near both magnetic poles (top figure) produce this cyclotron radiation. These shortwave signals are often referred to as DAM, since they fall in the decameter wavelength range. At these higher latitudes, where Jupiter’s magnetic field reaches as far out as Io, its field lines sweep rapidly past the ions and electrons shed into Io’s torus. This induces DAM radiation along the surface of the cyclotron cone (given in magenta in the middle figure). Jupiter’s DAM frequency reaches a maximum of 39.5 MHz near Jupiter’s cloud tops. At twice Jupiter’s radius the frequency is 3 MHz. Intermediate frequencies are created between these two extreme distances. Jupiter radiates two distinctive types of radio signatures in the DAM frequency range: *L-bursts –long duration static sounding like the swoosh of the waves; *S-bursts – short duration static resembling the crackling of a campfire. DAM radiation originates from at least 3 sources (A, B and C) that are fixed with respect to the planet’s rotating magnetic field. These sources are observed at around 20 MHz. They fall largely around one hemisphere (bottom figure). Source A is more than twice more likely to emit than either B or C. Jupiter’s magnetic storms depend on a combination of Io’s orbital position and the inclination of the respective radio source with respect to Earth. == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennae - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] = Books = == The Radio Sky and How to Observe It - by Jeff Lashley == [[:File:Ch0.pdf|Preface and Table of contents]] [[:File:Ch1.pdf|Chapter 1 - The Radio Sun]] [[:File:Ch2.pdf|Chapter 2 - Jupiter]] [[:File:Ch3.pdf|Chapter 3 - Meteors and Meteor Streams]] [[:File:Ch4.pdf|Chapter 4 - Beyond the Solar System]] [[:File:Ch5.pdf|Chapter 5 - Antennae]] [[:File:Ch6.pdf|Chapter 6 - Setting Up a Radio Astronomy Station]] [[:File:Ch7.pdf|Chapter 7 - Radio Hardware Theory]] [[:File:Ch8.pdf|Chapter 8 - Introduction to RF Electronics]] [[:File:Ch9.pdf|Chapter 9 - Building a Very Low Frequency Solar Flare Monitor]] [[:File:Ch10.pdf|Chapter 10 - Microwave Radio Telescope Projects]] [[:File:Ch11.pdf|Chapter 11 - Building a Jupiter Radio Telescope]] [[:File:Ch12.pdf|Chapter 12 - Building a Broad Band Solar Radio Telescope]] [[:File:Ch13.pdf|Chapter 13 - Data Logging and Data Processing]] [[:File:AppA.pdf|Appendices - Formulae; Bibliography; Suppliers, Groups, and Societies; Glossary]] = Articles = = Miscellaneous = == Radio Frequency Bands == {| class="wikitable", border = '1' |-style="background: silver" ! Band name ! Abbreviation ! Frequency ! Wavelength ! Usage |- | | | < 3 Hz | > 100 000 km | Natural and man-made electromagnetic noise |- | Extremely low frequency | ELF | 3 - 30 Hz | 100 000 - 10 000 km | Submarine communication |- | Super low frequency | SLF | 30 - 300 Hz | 10 000 - 1 000 km | Submarine communication |- | Ultra low frequency | ULF | 300 Hz - 3 kHz | 1 000 - 100 km | Submarine communication, Communication within mines |- | Very low frequency | VLF | 3 - 30 kHz | 100 - 10 km | Navigation, time signals, submarine communication, wireless heart rate monitors, geophysics |- | Low frequency | LF | 30 - 300 kHz | 10 - 1 km | Navigation, time signals, AM longwave broadcasting (Europe and parts of Asia), RFID, amateur radio |- | Medium frequency | MF | 300 kHz - 3 MHz | 1 km - 100 m | AM medium-wave broadcasts, amateur radio, avalanche beacons |- | High frequency | HF | 3 - 30 MHz | 100 m - 10 m | Shortwave broadcasts, citizens' band radio, amateur radio and over-the-horizon aviation communications, RFID, Over-the-horizon radar, Automatic link establishment (ALE) / Near Vertical Incidence Skywave (NVIS) radio communications, Marine and mobile radio telephony |- | Very high frequency | VHF | 30 - 300 MHz | 10 - 1 m | FM, television broadcasts and line-of-sight ground-to-aircraft and aircraft-to-aircraft communications. Land Mobile and Maritime Mobile communications, amateur radio, weather radio |- | Ultra high frequency | UHF | 300 MHz - 3 GHz | 1 m - 100 mm | Television broadcasts, microwave ovens, microwave devices/communications, mobile phones, wireless LAN, Bluetooth, ZigBee, GPS and two-way radios such as Land Mobile, FRS and GMRS radios, amateur radio |- | Super high frequency | SHF | 3 - 30 GHz | 100 - 10 mm | Microwave devices/communications, wireless LAN, most modern radars, communications satellites, satellite television broadcasting, DBS, amateur radio |- | Extremely high frequency | EHF | 30 - 300 GHz | 10 - 1 mm | High-frequency microwave radio relay, microwave remote sensing, amateur radio, directed-energy weapon, millimeter wave scanner |- | Terahertz or Tremendously high frequency | THz or THF | 300 GHz - 3 THz | 1 - 0.1 mm | Terahertz imaging, ultrafast molecular dynamics, condensed-matter physics, terahertz time-domain spectroscopy, terahertz computing/communications, sub-mm remote sensing, amateur radio |} 9f6b88de902d1b30bbe7d36bfc110aa0a4148b02 1668 1662 2011-09-28T08:08:48Z Gge002 52 wikitext text/x-wiki = Jovian Radio Storms = == Project Outline == [[File:Jupiter1.jpg|thumb|alt=Charged partical trajectory in Jupiter's magnetic field|Charged partical trajectory in Jupiter's magnetic field]] [[File:Jupiter2.jpg|thumb|alt=Origin of the different frequency emissions in Jupiter's magnetic field|Origin of the different frequency emissions in Jupiter's magnetic field]] [[File:Jupiter3.jpg|thumb|alt=Jupiter's A-, B- and C type radio burst|Jupiter's A-, B- and C type radio burst]] The project is suitable for 1-2 practically oriented students with broad interests, who do not mind “getting their hands dirty” every now and then, in addition to the time spent in front of the PC. #Contact persons – Georgi Genov, Kjetil Ullaland, Nikolai Østgaard, Kjell Aarsnes #Aim - To learn basic radio astronomy, to modify an existing radio telescope amplifier (RTA), to build the telescope’s antennas and to establish observational procedures. #Tasks #*Modifying the existing RTA for automatic sweep of the frequency range; #*Building the electronics required to establish the computer communication; #*Building and set up of the antennas of the radio telescope; #*Developing a simple software for data acquisition and preliminary data analysis; #*Performing tests and developing observational procedures. #Benefits – learn basic radio astronomy; get hands-on experience with applied electronics, data acquisition and data analysis, development of software for scientific purposes. #Background Two types of radio noise emitted by Jupiter have been detected – synchrotron and cyclotron. The latter is strong enough to be detected by small antennas on Earth’s surface. Charged particles spiraling around Jupiter’s magnetic field lines near both magnetic poles (top figure) produce this cyclotron radiation. These shortwave signals are often referred to as DAM, since they fall in the decameter wavelength range. At these higher latitudes, where Jupiter’s magnetic field reaches as far out as Io, its field lines sweep rapidly past the ions and electrons shed into Io’s torus. This induces DAM radiation along the surface of the cyclotron cone (given in magenta in the middle figure). Jupiter’s DAM frequency reaches a maximum of 39.5 MHz near Jupiter’s cloud tops. At twice Jupiter’s radius the frequency is 3 MHz. Intermediate frequencies are created between these two extreme distances. Jupiter radiates two distinctive types of radio signatures in the DAM frequency range: *L-bursts –long duration static sounding like the swoosh of the waves; *S-bursts – short duration static resembling the crackling of a campfire. DAM radiation originates from at least 3 sources (A, B and C) that are fixed with respect to the planet’s rotating magnetic field. These sources are observed at around 20 MHz. They fall largely around one hemisphere (bottom figure). Source A is more than twice more likely to emit than either B or C. Jupiter’s magnetic storms depend on a combination of Io’s orbital position and the inclination of the respective radio source with respect to Earth. == Original Radio JOVE Project == # JOVE Receiver Documentation # JOVE Antenna Documentation = Receivers - Construction and Theory = = Antennae - Construction and Theory = * [[:File:ParaboloidConcentrator.pdf|How to build a parabolic concentrator]] = Books = == The Radio Sky and How to Observe It - by Jeff Lashley == Preface and Table of contents Chapter 1 - The Radio Sun Chapter 2 - Jupiter Chapter 3 - Meteors and Meteor Streams Chapter 4 - Beyond the Solar System Chapter 5 - Antennae Chapter 6 - Setting Up a Radio Astronomy Station Chapter 7 - Radio Hardware Theory Chapter 8 - Introduction to RF Electronics Chapter 9 - Building a Very Low Frequency Solar Flare Monitor Chapter 10 - Microwave Radio Telescope Projects Chapter 11 - Building a Jupiter Radio Telescope Chapter 12 - Building a Broad Band Solar Radio Telescope Chapter 13 - Data Logging and Data Processing Appendices - Formulae; Bibliography; Suppliers, Groups, and Societies; Glossary = Articles = = Miscellaneous = == Radio Frequency Bands == {| class="wikitable", border = '1' |-style="background: silver" ! Band name ! Abbreviation ! Frequency ! Wavelength ! Usage |- | | | < 3 Hz | > 100 000 km | Natural and man-made electromagnetic noise |- | Extremely low frequency | ELF | 3 - 30 Hz | 100 000 - 10 000 km | Submarine communication |- | Super low frequency | SLF | 30 - 300 Hz | 10 000 - 1 000 km | Submarine communication |- | Ultra low frequency | ULF | 300 Hz - 3 kHz | 1 000 - 100 km | Submarine communication, Communication within mines |- | Very low frequency | VLF | 3 - 30 kHz | 100 - 10 km | Navigation, time signals, submarine communication, wireless heart rate monitors, geophysics |- | Low frequency | LF | 30 - 300 kHz | 10 - 1 km | Navigation, time signals, AM longwave broadcasting (Europe and parts of Asia), RFID, amateur radio |- | Medium frequency | MF | 300 kHz - 3 MHz | 1 km - 100 m | AM medium-wave broadcasts, amateur radio, avalanche beacons |- | High frequency | HF | 3 - 30 MHz | 100 m - 10 m | Shortwave broadcasts, citizens' band radio, amateur radio and over-the-horizon aviation communications, RFID, Over-the-horizon radar, Automatic link establishment (ALE) / Near Vertical Incidence Skywave (NVIS) radio communications, Marine and mobile radio telephony |- | Very high frequency | VHF | 30 - 300 MHz | 10 - 1 m | FM, television broadcasts and line-of-sight ground-to-aircraft and aircraft-to-aircraft communications. Land Mobile and Maritime Mobile communications, amateur radio, weather radio |- | Ultra high frequency | UHF | 300 MHz - 3 GHz | 1 m - 100 mm | Television broadcasts, microwave ovens, microwave devices/communications, mobile phones, wireless LAN, Bluetooth, ZigBee, GPS and two-way radios such as Land Mobile, FRS and GMRS radios, amateur radio |- | Super high frequency | SHF | 3 - 30 GHz | 100 - 10 mm | Microwave devices/communications, wireless LAN, most modern radars, communications satellites, satellite television broadcasting, DBS, amateur radio |- | Extremely high frequency | EHF | 30 - 300 GHz | 10 - 1 mm | High-frequency microwave radio relay, microwave remote sensing, amateur radio, directed-energy weapon, millimeter wave scanner |- | Terahertz or Tremendously high frequency | THz or THF | 300 GHz - 3 THz | 1 - 0.1 mm | Terahertz imaging, ultrafast molecular dynamics, condensed-matter physics, terahertz time-domain spectroscopy, terahertz computing/communications, sub-mm remote sensing, amateur radio |} 4e7c66ee35fc8200405c1f9b20badfd108b5b433 6 372 1637 2011-09-21T21:08:33Z Gge002 52 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 373 1640 2011-09-22T06:39:21Z Gge002 52 Particle trajectory in Jupiter's magnetic fieald wikitext text/x-wiki Particle trajectory in Jupiter's magnetic fieald 9e166b23f96dabbad43b138db68bcf3ae4f5644d 6 374 1641 2011-09-22T06:40:27Z Gge002 52 Jupiter radio frequency emissions wikitext text/x-wiki Jupiter radio frequency emissions 635adec04405b513198775e71c01e206ef5a97d1 6 375 1642 2011-09-22T06:41:06Z Gge002 52 Jupiter - A-, B- and C type radio bursts wikitext text/x-wiki Jupiter - A-, B- and C type radio bursts 9ac8bd711dedbc2a39a8f0a422fc01f90ffe8e2b 6 377 1647 2011-09-22T11:45:19Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.1 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.1 d0ebb774a08fbea1d29e6a6e9f67f405cff25070 6 378 1648 2011-09-22T11:46:04Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.2 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.2 1bb5f89f51aea485ad6bdf2cb18e5f069a6bc986 6 379 1649 2011-09-22T11:46:16Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.3 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.3 d1bbb1af788f095bfa9be1acad25633c8391c853 6 380 1650 2011-09-22T11:46:31Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.4 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.4 0f5fdd59e1970e7c1660fba57aad7a1d1402916b 6 381 1651 2011-09-22T11:57:29Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.5 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.5 d975e0042c1503fa5726c0cc11037e44ac60c393 6 382 1652 2011-09-22T11:57:41Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.6 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.6 5d571dfc8ab8f71d87d74b55117579cff3d99273 6 383 1653 2011-09-22T11:57:52Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.7 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.7 cc528e355a15c9fe5136784609a485291d6a6571 6 384 1654 2011-09-22T11:58:35Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.8 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.8 5e44f2b4cf5e21919569dea998b6fe30750a7a43 6 385 1655 2011-09-22T11:58:48Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.9 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.9 f5dc2c91ca68fd8566198bdec77a1d20729dcb16 6 386 1656 2011-09-22T11:59:03Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.10 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.10 a6b14e61f8c2723d09b319f2c4afa581f18787e7 6 387 1657 2011-09-22T11:59:34Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.11 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.11 8bf1eab4d6641b03a40a21a56b64c7d3023fca95 6 388 1658 2011-09-22T12:01:21Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.12 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.12 38a41c7a4c8d483a2994e03dba274d18a4516e81 6 389 1659 2011-09-22T12:01:31Z Gge002 52 The Radio Sky and How to Observe It - by Jeff Lashley Ch.13 wikitext text/x-wiki The Radio Sky and How to Observe It - by Jeff Lashley Ch.13 bdabf4e04f6acb109cf08da3193009251ef4997d 0 348 1664 1608 2011-09-27T12:39:08Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Researcher's corner'' [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === 3a3b8b2a78542ed6e0a283dacd2f5d5a98f14e5c 1665 1664 2011-09-27T12:39:29Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === 9b907c9995d6da17bc51f1314f2931416e777163 1666 1665 2011-09-27T12:46:03Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === == Theses == === Master === === PhD === f4bd3047f379a32027c981e1cc82ce070cfa8506 1669 1666 2011-09-28T09:40:28Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] == Theses == === Master === === PhD === 559eabd791f9436409111e383354015732cf4ab7 0 348 1670 1669 2011-09-28T09:40:52Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === bdf7cdf7dc2a35b922a946ad39a33d1677d483d9 1675 1670 2011-10-17T10:38:54Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === 719623347001d1c86284f1e56935ed6120927c9b 1676 1675 2011-10-17T10:39:28Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === fb55a390d0814a02f0b4327bb25d39584db9027e 1677 1676 2011-10-24T09:18:23Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === c703cea219ada0437b695cc1b2bd6c723cb411b6 1678 1677 2011-11-03T13:43:09Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october), Trygve Buanes * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === 18acb8ff2e803be014702873efc98121b264514b 1681 1678 2011-11-14T13:21:52Z Hsa061 18 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october), Trygve Buanes * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === d0d0f855ad46802fd03ba200afc7865b87c1abde 1682 1681 2011-11-14T13:24:50Z Hsa061 18 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october), Trygve Buanes * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === 1e9f85851a9e00fd48e4cc7580cffad7ecbdde4e 1683 1682 2011-11-14T13:40:25Z Hsa061 18 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * Presentation [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Presentation of the possibilities of Norwegian membership of CTA, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === 15377e2f8406a340ad579c308962254c5ab48940 1684 1683 2011-11-14T13:43:02Z Hsa061 18 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === 5ae544e45da9bb878a303730a5a216ce09b0db55 1685 1684 2011-11-15T08:42:22Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === 88ef9d62137e72ec1e186a621636de58d09a329d 1686 1685 2011-11-15T09:03:44Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) == Theses == === Master === === PhD === cf9fee72164a3b0fa7e03f92758f0cb4569663b8 1697 1686 2011-12-23T08:21:28Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844] (25. november 2011) == Theses == === Master === === PhD === 33290e3fc81d13aeed5aa3b7cc1c2c9de300ee14 1698 1697 2011-12-23T08:22:48Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844 ATL-COM-PHYS-2011-1619] (25. november 2011) == Theses == === Master === === PhD === f73a7f4275f9e002379d1dcbe05fbecd12f74f43 0 1 1671 1630 2011-10-11T16:11:34Z Tre043 64 wikitext text/x-wiki <big>'''Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis] Wiki'''</big> * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] * [[DAMARA]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [[Nano Physics| Nano Physics Group]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 4d7a4befb1b0130f65a2e3f97977701f9dba7a18 0 28 1679 1138 2011-11-07T15:44:41Z Nfyku 4 Removed xset +fp command as it seems to crash the X-client wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. ssh -X mikroserver2 /prog/design_kits/micro.init.csh ==Starte opp IC studio== Skriv i et terminalvindu: <del>xset +fp tcp/mikroserver2:7100</del> # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 tcsh source /prog/design_kits/mentor_init/mentor-s35d4.csh ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. Om du ønsker å bruke Mentor programmene fra en Windows-PC så se på forklaringene i [[Teknisk hjelp]] ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/htmldocs/ start f.eks. firefox slik: firefox file:///prog/mentor/mgc/ic.2005.1/shared/htmldocs/_bk_icda/_bk_icda.html Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: acroread /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". [[Category:Mikroelektronikk]] 9a81f20da21376b38af8f72567274224fd61f51f 0 202 1680 1663 2011-11-10T12:29:22Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf|Elementary Physics of P-N Junctions]] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html|The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 2396dea608ba2f73a718485876dfde073b796e17 1695 1680 2011-11-29T08:21:33Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] == Nettressurser == * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf Elementary Physics of P-N Junctions]] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] f6a9e435e8887828c4dd8643f1ff15c1d7c3d483 1696 1695 2011-11-29T08:22:51Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf Elementary Physics of P-N Junctions]] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 92ea59ca92565bd47df6eaabeb2519c245a50c59 0 139 1687 1044 2011-11-22T11:21:02Z St01355 57 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2011 === Special pensum Course: Introduction to ATLAS November 2011 Wolfgang Liebig, Wolfgang.Liebig at cern.ch ATLAS detector ATLAS physics ATLAS reconstruction and performance ATLAS tools and practicalities === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] ab694b97eced4d4198798f8f9efa09ddfbe9ad7d 1688 1687 2011-11-22T11:29:59Z St01355 57 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * [[ATLAS detector]] * [[ATLAS physics]] * [[ATLAS reconstruction and performance]] * [[ATLAS tools and practicalities]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] b49315597a8e7b47398aa37ef188b4426d4d3a21 1689 1688 2011-11-22T11:35:43Z St01355 57 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector]] * ATLAS physics [[File:ATLASphyics]] * ATLAS reconstruction and performance [[File:ATLASperformance]] * ATLAS tools and practicalities [[File:ATLAStools]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] e0799cc98be1a1bdabf073fcbc3f6af7bb031d55 1691 1689 2011-11-22T11:40:31Z St01355 57 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] d6aeeba9a1e03ff3f963038ebc473bfb9582ca99 6 392 1690 2011-11-22T11:39:26Z St01355 57 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 393 1692 2011-11-22T11:41:02Z St01355 57 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 394 1693 2011-11-22T11:41:31Z St01355 57 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 395 1694 2011-11-22T11:41:53Z St01355 57 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 331 1699 1577 2012-01-05T11:11:43Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 2329b2e89e44d27168bac2ed8a1fc48a594d4436 1706 1699 2012-01-12T08:30:34Z Kmo078 65 Added a link to DarkSusy installation tips wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] cc0a8454ce4bffdf77b50ee873acdc19316f8798 0 396 1700 2012-01-05T11:12:16Z Hsa061 18 Created page with '* Indico access: https://www.cta-observatory.org/indico/userRegistration.py' wikitext text/x-wiki * Indico access: https://www.cta-observatory.org/indico/userRegistration.py aac971271d78aa481f6a468d2418c3b1ce2311f7 1701 1700 2012-01-05T12:43:39Z Hsa061 18 wikitext text/x-wiki * Indico access: https://www.cta-observatory.org/indico/userRegistration.py * The Design Concepts report: http://uk.arXiv.org/abs/1008.3703 * General CTA meetings: https://hepwww.rl.ac.uk/CTAforum2010/ 5f562db1c9593ca5652e5a324e7df0cf25d2b4d9 1702 1701 2012-01-05T12:46:14Z Hsa061 18 wikitext text/x-wiki * Indico access: https://www.cta-observatory.org/indico/userRegistration.py * The Design Concepts report: http://uk.arXiv.org/abs/1008.3703 * General CTA meetings: https://hepwww.rl.ac.uk/CTAforum2010/ * Link workshop on Physics 2010: http://indico.cern.ch/conferenceDisplay.py?confId=105442 * End-to-End Calibration workshop 2011: http://www.cta-observatory.org/indico/conferenceDisplay.py?confId=111 55c2208024df7c0a9bf34825c5ddbd0edd5c5a55 1703 1702 2012-01-05T12:49:46Z Hsa061 18 wikitext text/x-wiki * Indico access: https://www.cta-observatory.org/indico/userRegistration.py * The Design Concepts report: http://uk.arXiv.org/abs/1008.3703 * General CTA meetings: https://hepwww.rl.ac.uk/CTAforum2010/ * Link workshop on Physics 2010: http://indico.cern.ch/conferenceDisplay.py?confId=105442 * End-to-End Calibration workshop 2011: http://www.cta-observatory.org/indico/conferenceDisplay.py?confId=111 * ATAC mailing list: cta-wp-atac@cta-observatory.org 2bdb3c4ebd0e028c765207a49a47644c9d23e54e 1704 1703 2012-01-05T12:52:26Z Hsa061 18 wikitext text/x-wiki * Main web-page: http://www.cta-observatory.org/ * Indico access: https://www.cta-observatory.org/indico/userRegistration.py * The Design Concepts report: http://uk.arXiv.org/abs/1008.3703 * General CTA meetings: https://hepwww.rl.ac.uk/CTAforum2010/ * Link workshop on Physics 2010: http://indico.cern.ch/conferenceDisplay.py?confId=105442 * End-to-End Calibration workshop 2011: http://www.cta-observatory.org/indico/conferenceDisplay.py?confId=111 * ATAC mailing list: cta-wp-atac@cta-observatory.org * PHYS mailing list: cta-wp-phys@cta-observatory.org d1ec1c33ffc1583dcdb405359a6416a82322a322 6 397 1705 2012-01-10T11:17:52Z Nfyst 67 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 398 1707 2012-01-12T08:34:04Z Kmo078 65 Created a page with installation experience w/ DarkSusy wikitext text/x-wiki When installing [http://www.physto.se/~edsjo/darksusy/ DarkSusy], make sure to [[Category:Installation]] 1d38c8a066168b318d8968777a4824ee1a5c58b9 1708 1707 2012-01-12T08:41:15Z Kmo078 65 Created a page with installation experience w/ DarkSusy wikitext text/x-wiki To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' [[Category:Installing]] 16851655db9266b21ff42db63ab70488554a594b 1709 1708 2012-01-12T08:52:09Z Kmo078 65 wikitext text/x-wiki To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' If you run run mac osx 10.6, the c++ and fortran compilers will not compile for the same architecture together unless you modify the configure command to ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. [[Category:Installing]] 2be383c8ca27764582d477b36b0fb72967f1bba2 1710 1709 2012-01-12T08:53:05Z Kmo078 65 wikitext text/x-wiki To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' *If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' *If you run run (tested on mac osx 10.6), the c++ and fortran compilers will not compile for the same architecture together unless you modify the configure command to ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. [[Category:Installing]] 3b25b27b2e18b9d2da72c0a9b450832a83d5a81c 1711 1710 2012-01-12T08:59:51Z Kmo078 65 wikitext text/x-wiki To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' *If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' *If you run mac (tested on mac osx 10.6), the c++ and fortran compilers will not compile for the same architecture unless you modify the configure command to ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. [[Category:Installing]] 25d6a33b2f02be361e8f1db0e259b18e9174c313 1717 1711 2012-01-18T10:50:56Z Kmo078 65 Added info on how to compile subprograms wikitext text/x-wiki ==Installing== To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' *If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' *If you run mac (tested on mac osx 10.6), the c++ and fortran compilers will not compile for the same architecture unless you modify the configure command to ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. ==Compiling programs== To compile your own Fortran program written with DarkSusy, the call should be similar to (if you've configured with gfortran): ''gfortran -I$PWD/../include -L$PWD/../lib -o ProgramName ProgramName.f -ldarksusy -lFH -lHB'' For examples, one can look in the makefile in ''test'', the one above compiles ''dstest'' [[Category:Installing]] b9fa1667154a62bae09e68fa35e3ad18b670ab18 1718 1717 2012-01-18T10:51:41Z Kmo078 65 wikitext text/x-wiki ==Installing== To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' *If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' *If you run mac (tested on mac osx 10.6), the c++ and fortran compilers will not compile for the same architecture unless you modify the configure command to ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. ==Compiling programs== To compile your own Fortran program written with DarkSusy, the call should be similar to (if you've configured with gfortran): ''gfortran -I$PWD/../include -L$PWD/../lib -o ProgramName ProgramName.f -ldarksusy -lFH -lHB'' For examples, one can look in the makefile in ''test''. [[Category:Installing]] 7c9de6330714771f10684f53842be68a6b507c4f 0 25 1712 1291 2012-01-17T08:25:34Z Nfyku 4 removed link to hdl-designer wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) [[Category:Mikroelektronikk]] cd97244bcab965d278c006f59d5bffe1d7fd300e 0 33 1713 1104 2012-01-17T09:55:24Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[http://www.edn.com/contents/images/46098.pdf 10 tips for generating reusable VHDL]] [[http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide]] [[Category:Mikroelektronikk]] e54699caaa127773d35d79872a7526271be3f869 0 234 1714 1241 2012-01-17T21:51:34Z Tbu082 19 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]] 60ae2a2f2fa06dba04cf59d3cee6d6b99ad5a131 0 317 1715 1595 2012-01-18T07:51:36Z Dfe002 7 /* Software */ wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ [[Setting Up PetaLinux System]] Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk] [[Get readout box up and running]] == Download section == #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 [[Category:Mikroelektronikk]] 7ed492c30336a3e82f9a4eb6e575b5a48c51a343 0 399 1716 2012-01-18T07:57:04Z Dfe002 7 Created page with '- Use Impact to configure FPGA(s) - start TFTP server - Use XMD: <pre> $ connect mb mdm -debugdevice devicenr 4 $ dow u-boot.elf </pre> Open serial console <pre> $ tftp </pre> …' wikitext text/x-wiki - Use Impact to configure FPGA(s) - start TFTP server - Use XMD: <pre> $ connect mb mdm -debugdevice devicenr 4 $ dow u-boot.elf </pre> Open serial console <pre> $ tftp </pre> Boot Linux kernel: <pre> $ bootm </pre> Adjust MAC address and load startup script: <pre> $ ifconfig eth0 hw ether 00:0a:35:02:4b:a8 $ udhcpc $ /home/test/load.sh </pre> d7e8954c8d19bf78d40483933d2d331e0527ba37 0 4 1719 1417 2012-01-20T08:45:53Z Stud4729 6 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br> '''v 1.5 (17.08.2010)'''<br> <ul> <li>Fix done by Attiq Ur Rehman:<br> There is minor change in the "fifo wrapper":<br> Line #73 new signal cnt_dn<br> Line #91 comparison with "read_counter"<br> Line #170,172,174 check of possible logical conditions<br> This file was used for the RCU firmware (from 10th July and on wards) to fix the Erroneous behavior causing busy condition. </li> </ul> <br> '''v 1.6 (20.01.2012)'''<br> <ul> <li>Single l2 messages does not generate CDH</li> <li>Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register.</li> <li>Cleaned up code and removed commented lines (RoI is now gone)</li> <li>Minor changes to DAQ header error word</li> <li>New output: sync - software trigger decoded from RoC = 0xD</li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.5_source_files.rar Firmware v 1.5 - VHDL files, including testbench]<br> <br> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.6.pdf Specification/design document for Firmware version 1.6] (Updated 20.01.12) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.6_source_files.zip Firmware v 1.6 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool]. Note that version 9.0 gives errors when trying to program the FPGA. [ftp://ftp.actel.com/downloads/flashpro/FlashPro86.zip Version 8.6] is the last version that works for the Actel on the RCU.<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 309e3e329c9393a3fe905e4ea4cae40adcf3e530 1720 1719 2012-01-30T10:56:31Z Dfe002 7 Added version 2.9 changes wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> '''2.9 (30.1.2012)'''<br> <ul> <li> Updated udhcpc <li> Updated rcS (udhcpc parameters, ntp timeserver, bootscript execution order) <li> modified nfsmount_all to only mount dcbrw and dcbro <li> added _S05restartreadback.sh, S27enable_ttcrx.sh, S31unsetOldMode.sh, S52startntp.sh to /etc/boot <li> removed S30rcu-conf.sh, S31setoldmode from /etc/boot <li> disabled CONFIG_DEBUG_SLAB in kernel </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br> '''v 1.5 (17.08.2010)'''<br> <ul> <li>Fix done by Attiq Ur Rehman:<br> There is minor change in the "fifo wrapper":<br> Line #73 new signal cnt_dn<br> Line #91 comparison with "read_counter"<br> Line #170,172,174 check of possible logical conditions<br> This file was used for the RCU firmware (from 10th July and on wards) to fix the Erroneous behavior causing busy condition. </li> </ul> <br> '''v 1.6 (20.01.2012)'''<br> <ul> <li>Single l2 messages does not generate CDH</li> <li>Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register.</li> <li>Cleaned up code and removed commented lines (RoI is now gone)</li> <li>Minor changes to DAQ header error word</li> <li>New output: sync - software trigger decoded from RoC = 0xD</li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.5_source_files.rar Firmware v 1.5 - VHDL files, including testbench]<br> <br> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.6.pdf Specification/design document for Firmware version 1.6] (Updated 20.01.12) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.6_source_files.zip Firmware v 1.6 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool]. Note that version 9.0 gives errors when trying to program the FPGA. [ftp://ftp.actel.com/downloads/flashpro/FlashPro86.zip Version 8.6] is the last version that works for the Actel on the RCU.<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 1a99e172f0c6d88e6a853da738fc36b4ea643157 1721 1720 2012-01-30T11:02:25Z Dfe002 7 /* Download Section */ wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> '''2.9 (30.1.2012)'''<br> <ul> <li> Updated udhcpc <li> Updated rcS (udhcpc parameters, ntp timeserver, bootscript execution order) <li> modified nfsmount_all to only mount dcbrw and dcbro <li> added _S05restartreadback.sh, S27enable_ttcrx.sh, S31unsetOldMode.sh, S52startntp.sh to /etc/boot <li> removed S30rcu-conf.sh, S31setoldmode from /etc/boot <li> disabled CONFIG_DEBUG_SLAB in kernel </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <li>'''Version 2.9: '''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0031.hex hex file for dcs0031] | [[Firmware files for boards 30 - 1400]] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br> '''v 1.5 (17.08.2010)'''<br> <ul> <li>Fix done by Attiq Ur Rehman:<br> There is minor change in the "fifo wrapper":<br> Line #73 new signal cnt_dn<br> Line #91 comparison with "read_counter"<br> Line #170,172,174 check of possible logical conditions<br> This file was used for the RCU firmware (from 10th July and on wards) to fix the Erroneous behavior causing busy condition. </li> </ul> <br> '''v 1.6 (20.01.2012)'''<br> <ul> <li>Single l2 messages does not generate CDH</li> <li>Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register.</li> <li>Cleaned up code and removed commented lines (RoI is now gone)</li> <li>Minor changes to DAQ header error word</li> <li>New output: sync - software trigger decoded from RoC = 0xD</li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.5_source_files.rar Firmware v 1.5 - VHDL files, including testbench]<br> <br> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.6.pdf Specification/design document for Firmware version 1.6] (Updated 20.01.12) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.6_source_files.zip Firmware v 1.6 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool]. Note that version 9.0 gives errors when trying to program the FPGA. [ftp://ftp.actel.com/downloads/flashpro/FlashPro86.zip Version 8.6] is the last version that works for the Actel on the RCU.<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 3e82d25e4f155d27c855a4564e26e46706f9a5f7 0 400 1722 2012-01-30T11:23:35Z Dfe002 7 Created page with '[http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0030.hex dcs0030] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.…' wikitext text/x-wiki [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0030.hex dcs0030] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0031.hex dcs0031] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0032.hex dcs0032] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0033.hex dcs0033] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0034.hex dcs0034] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0035.hex dcs0035] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0036.hex dcs0036] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0037.hex dcs0037] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0038.hex dcs0038] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0039.hex dcs0039] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0040.hex dcs0040] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0041.hex dcs0041] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0042.hex dcs0042] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0043.hex dcs0043] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0044.hex dcs0044] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0045.hex dcs0045] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0046.hex dcs0046] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0047.hex dcs0047] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0048.hex dcs0048] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0049.hex dcs0049] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0050.hex dcs0050] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0051.hex dcs0051] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0052.hex dcs0052] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0053.hex dcs0053] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0054.hex dcs0054] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0055.hex dcs0055] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0056.hex dcs0056] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0057.hex dcs0057] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0058.hex dcs0058] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0059.hex dcs0059] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0060.hex dcs0060] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0061.hex dcs0061] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0062.hex dcs0062] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0063.hex dcs0063] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0064.hex dcs0064] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0065.hex dcs0065] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0066.hex dcs0066] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0067.hex dcs0067] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0068.hex dcs0068] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0069.hex dcs0069] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0070.hex dcs0070] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0071.hex dcs0071] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0072.hex dcs0072] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0073.hex dcs0073] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0074.hex dcs0074] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0075.hex dcs0075] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0076.hex dcs0076] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0077.hex dcs0077] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0078.hex dcs0078] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0079.hex dcs0079] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0080.hex dcs0080] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0081.hex dcs0081] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0082.hex dcs0082] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0083.hex dcs0083] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0084.hex dcs0084] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0085.hex dcs0085] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0086.hex dcs0086] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0087.hex dcs0087] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0088.hex dcs0088] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0089.hex dcs0089] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0090.hex dcs0090] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0091.hex dcs0091] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0092.hex dcs0092] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0093.hex dcs0093] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0094.hex dcs0094] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0095.hex dcs0095] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0096.hex dcs0096] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0097.hex dcs0097] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0098.hex dcs0098] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0099.hex dcs0099] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0100.hex dcs0100] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0101.hex dcs0101] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0102.hex dcs0102] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0103.hex dcs0103] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0104.hex dcs0104] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0105.hex dcs0105] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0106.hex dcs0106] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0107.hex dcs0107] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0108.hex dcs0108] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0109.hex dcs0109] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0110.hex dcs0110] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0111.hex dcs0111] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0112.hex dcs0112] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0113.hex dcs0113] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0114.hex dcs0114] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0115.hex dcs0115] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0116.hex dcs0116] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0117.hex dcs0117] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0118.hex dcs0118] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0119.hex dcs0119] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0120.hex dcs0120] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0121.hex dcs0121] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0122.hex dcs0122] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0123.hex dcs0123] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0124.hex dcs0124] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0125.hex dcs0125] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0126.hex dcs0126] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0127.hex dcs0127] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0128.hex dcs0128] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0129.hex dcs0129] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0130.hex dcs0130] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0131.hex dcs0131] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0132.hex dcs0132] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0133.hex dcs0133] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0134.hex dcs0134] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0135.hex dcs0135] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0136.hex dcs0136] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0137.hex dcs0137] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0138.hex dcs0138] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0139.hex dcs0139] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0140.hex dcs0140] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0141.hex dcs0141] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0142.hex dcs0142] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0143.hex dcs0143] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0144.hex dcs0144] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0145.hex dcs0145] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0146.hex dcs0146] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0147.hex dcs0147] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0148.hex dcs0148] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0149.hex dcs0149] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0150.hex dcs0150] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0151.hex dcs0151] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0152.hex dcs0152] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0153.hex dcs0153] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0154.hex dcs0154] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0155.hex dcs0155] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0156.hex dcs0156] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0157.hex dcs0157] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0158.hex dcs0158] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0159.hex dcs0159] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0160.hex dcs0160] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0161.hex dcs0161] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0162.hex dcs0162] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0163.hex dcs0163] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0164.hex dcs0164] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0165.hex dcs0165] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0166.hex dcs0166] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0167.hex dcs0167] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0168.hex dcs0168] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0169.hex dcs0169] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0170.hex dcs0170] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0171.hex dcs0171] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0172.hex dcs0172] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0173.hex dcs0173] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0174.hex dcs0174] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0175.hex dcs0175] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0176.hex dcs0176] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0177.hex dcs0177] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0178.hex dcs0178] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0179.hex dcs0179] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0180.hex dcs0180] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0181.hex dcs0181] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0182.hex dcs0182] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0183.hex dcs0183] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0184.hex dcs0184] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0185.hex dcs0185] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0186.hex dcs0186] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0187.hex dcs0187] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0188.hex dcs0188] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0189.hex dcs0189] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0190.hex dcs0190] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0191.hex dcs0191] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0192.hex dcs0192] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0193.hex dcs0193] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0194.hex dcs0194] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0195.hex dcs0195] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0196.hex dcs0196] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0197.hex dcs0197] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0198.hex dcs0198] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0199.hex dcs0199] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0200.hex dcs0200] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0201.hex dcs0201] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0202.hex dcs0202] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0203.hex dcs0203] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0204.hex dcs0204] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0205.hex dcs0205] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0206.hex dcs0206] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0207.hex dcs0207] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0208.hex dcs0208] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0209.hex dcs0209] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0210.hex dcs0210] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0211.hex dcs0211] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0212.hex dcs0212] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0213.hex dcs0213] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0214.hex dcs0214] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0215.hex dcs0215] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0216.hex dcs0216] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0217.hex dcs0217] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0218.hex dcs0218] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0219.hex dcs0219] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0220.hex dcs0220] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0221.hex dcs0221] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0222.hex dcs0222] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0223.hex dcs0223] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0224.hex dcs0224] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0225.hex dcs0225] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0226.hex dcs0226] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0227.hex dcs0227] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0228.hex dcs0228] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0229.hex dcs0229] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0230.hex dcs0230] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0231.hex dcs0231] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0232.hex dcs0232] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0233.hex dcs0233] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0234.hex dcs0234] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0235.hex dcs0235] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0236.hex dcs0236] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0237.hex dcs0237] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0238.hex dcs0238] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0239.hex dcs0239] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0240.hex dcs0240] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0241.hex dcs0241] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0242.hex dcs0242] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0243.hex dcs0243] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0244.hex dcs0244] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0245.hex dcs0245] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0246.hex dcs0246] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0247.hex dcs0247] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0248.hex dcs0248] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0249.hex dcs0249] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0250.hex dcs0250] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0251.hex dcs0251] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0252.hex dcs0252] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0253.hex dcs0253] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0254.hex dcs0254] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0255.hex dcs0255] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0256.hex dcs0256] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0257.hex dcs0257] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0258.hex dcs0258] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0259.hex dcs0259] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0260.hex dcs0260] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0261.hex dcs0261] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0262.hex dcs0262] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0263.hex dcs0263] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0264.hex dcs0264] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0265.hex dcs0265] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0266.hex dcs0266] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0267.hex dcs0267] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0268.hex dcs0268] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0269.hex dcs0269] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0270.hex dcs0270] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0271.hex dcs0271] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0272.hex dcs0272] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0273.hex dcs0273] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0274.hex dcs0274] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0275.hex dcs0275] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0276.hex dcs0276] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0277.hex dcs0277] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0278.hex dcs0278] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0279.hex dcs0279] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0280.hex dcs0280] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0281.hex dcs0281] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0282.hex dcs0282] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0283.hex dcs0283] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0284.hex dcs0284] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0285.hex dcs0285] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0286.hex dcs0286] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0287.hex dcs0287] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0288.hex dcs0288] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0289.hex dcs0289] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0290.hex dcs0290] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0291.hex dcs0291] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0292.hex dcs0292] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0293.hex dcs0293] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0294.hex dcs0294] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0295.hex dcs0295] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0296.hex dcs0296] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0297.hex dcs0297] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0298.hex dcs0298] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0299.hex dcs0299] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0300.hex dcs0300] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0301.hex dcs0301] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0302.hex dcs0302] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0303.hex dcs0303] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0304.hex dcs0304] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0305.hex dcs0305] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0306.hex dcs0306] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0307.hex dcs0307] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0308.hex dcs0308] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0309.hex dcs0309] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0310.hex dcs0310] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0311.hex dcs0311] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0312.hex dcs0312] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0313.hex dcs0313] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0314.hex dcs0314] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0315.hex dcs0315] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0316.hex dcs0316] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0317.hex dcs0317] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0318.hex dcs0318] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0319.hex dcs0319] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0320.hex dcs0320] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0321.hex dcs0321] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0322.hex dcs0322] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0323.hex dcs0323] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0324.hex dcs0324] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0325.hex dcs0325] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0326.hex dcs0326] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0327.hex dcs0327] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0328.hex dcs0328] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0329.hex dcs0329] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0330.hex dcs0330] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0331.hex dcs0331] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0332.hex dcs0332] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0333.hex dcs0333] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0334.hex dcs0334] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0335.hex dcs0335] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0336.hex dcs0336] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0337.hex dcs0337] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0338.hex dcs0338] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0339.hex dcs0339] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0340.hex dcs0340] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0341.hex dcs0341] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0342.hex dcs0342] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0343.hex dcs0343] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0344.hex dcs0344] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0345.hex dcs0345] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0346.hex dcs0346] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0347.hex dcs0347] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0348.hex dcs0348] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0349.hex dcs0349] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0350.hex dcs0350] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0351.hex dcs0351] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0352.hex dcs0352] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0353.hex dcs0353] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0354.hex dcs0354] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0355.hex dcs0355] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0356.hex dcs0356] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0357.hex dcs0357] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0358.hex dcs0358] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0359.hex dcs0359] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0360.hex dcs0360] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0361.hex dcs0361] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0362.hex dcs0362] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0363.hex dcs0363] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0364.hex dcs0364] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0365.hex dcs0365] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0366.hex dcs0366] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0367.hex dcs0367] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0368.hex dcs0368] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0369.hex dcs0369] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0370.hex dcs0370] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0371.hex dcs0371] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0372.hex dcs0372] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0373.hex dcs0373] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0374.hex dcs0374] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0375.hex dcs0375] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0376.hex dcs0376] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0377.hex dcs0377] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0378.hex dcs0378] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0379.hex dcs0379] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0380.hex dcs0380] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0381.hex dcs0381] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0382.hex dcs0382] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0383.hex dcs0383] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0384.hex dcs0384] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0385.hex dcs0385] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0386.hex dcs0386] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0387.hex dcs0387] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0388.hex dcs0388] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0389.hex dcs0389] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0390.hex dcs0390] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0391.hex dcs0391] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0392.hex dcs0392] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0393.hex dcs0393] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0394.hex dcs0394] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0395.hex dcs0395] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0396.hex dcs0396] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0397.hex dcs0397] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0398.hex dcs0398] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0399.hex dcs0399] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0400.hex dcs0400] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0401.hex dcs0401] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0402.hex dcs0402] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0403.hex dcs0403] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0404.hex dcs0404] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0405.hex dcs0405] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0406.hex dcs0406] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0407.hex dcs0407] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0408.hex dcs0408] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0409.hex dcs0409] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0410.hex dcs0410] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0411.hex dcs0411] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0412.hex dcs0412] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0413.hex dcs0413] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0414.hex dcs0414] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0415.hex dcs0415] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0416.hex dcs0416] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0417.hex dcs0417] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0418.hex dcs0418] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0419.hex dcs0419] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0420.hex dcs0420] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0421.hex dcs0421] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0422.hex dcs0422] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0423.hex dcs0423] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0424.hex dcs0424] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0425.hex dcs0425] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0426.hex dcs0426] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0427.hex dcs0427] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0428.hex dcs0428] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0429.hex dcs0429] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0430.hex dcs0430] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0431.hex dcs0431] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0432.hex dcs0432] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0433.hex dcs0433] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0434.hex dcs0434] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0435.hex dcs0435] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0436.hex dcs0436] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0437.hex dcs0437] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0438.hex dcs0438] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0439.hex dcs0439] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0440.hex dcs0440] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0441.hex dcs0441] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0442.hex dcs0442] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0443.hex dcs0443] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0444.hex dcs0444] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0445.hex dcs0445] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0446.hex dcs0446] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0447.hex dcs0447] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0448.hex dcs0448] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0449.hex dcs0449] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0450.hex dcs0450] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0451.hex dcs0451] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0452.hex dcs0452] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0453.hex dcs0453] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0454.hex dcs0454] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0455.hex dcs0455] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0456.hex dcs0456] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0457.hex dcs0457] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0458.hex dcs0458] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0459.hex dcs0459] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0460.hex dcs0460] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0461.hex dcs0461] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0462.hex dcs0462] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0463.hex dcs0463] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0464.hex dcs0464] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0465.hex dcs0465] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0466.hex dcs0466] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0467.hex dcs0467] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0468.hex dcs0468] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0469.hex dcs0469] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0470.hex dcs0470] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0471.hex dcs0471] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0472.hex dcs0472] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0473.hex dcs0473] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0474.hex dcs0474] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0475.hex dcs0475] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0476.hex dcs0476] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0477.hex dcs0477] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0478.hex dcs0478] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0479.hex dcs0479] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0480.hex dcs0480] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0481.hex dcs0481] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0482.hex dcs0482] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0483.hex dcs0483] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0484.hex dcs0484] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0485.hex dcs0485] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0486.hex dcs0486] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0487.hex dcs0487] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0488.hex dcs0488] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0489.hex dcs0489] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0490.hex dcs0490] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0491.hex dcs0491] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0492.hex dcs0492] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0493.hex dcs0493] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0494.hex dcs0494] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0495.hex dcs0495] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0496.hex dcs0496] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0497.hex dcs0497] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0498.hex dcs0498] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0499.hex dcs0499] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0500.hex dcs0500] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0501.hex dcs0501] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0502.hex dcs0502] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0503.hex dcs0503] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0504.hex dcs0504] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0505.hex dcs0505] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0506.hex dcs0506] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0507.hex dcs0507] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0508.hex dcs0508] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0509.hex dcs0509] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0510.hex dcs0510] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0511.hex dcs0511] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0512.hex dcs0512] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0513.hex dcs0513] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0514.hex dcs0514] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0515.hex dcs0515] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0516.hex dcs0516] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0517.hex dcs0517] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0518.hex dcs0518] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0519.hex dcs0519] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0520.hex dcs0520] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0521.hex dcs0521] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0522.hex dcs0522] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0523.hex dcs0523] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0524.hex dcs0524] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0525.hex dcs0525] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0526.hex dcs0526] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0527.hex dcs0527] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0528.hex dcs0528] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0529.hex dcs0529] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0530.hex dcs0530] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0531.hex dcs0531] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0532.hex dcs0532] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0533.hex dcs0533] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0534.hex dcs0534] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0535.hex dcs0535] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0536.hex dcs0536] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0537.hex dcs0537] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0538.hex dcs0538] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0539.hex dcs0539] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0540.hex dcs0540] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0541.hex dcs0541] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0542.hex dcs0542] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0543.hex dcs0543] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0544.hex dcs0544] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0545.hex dcs0545] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0546.hex dcs0546] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0547.hex dcs0547] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0548.hex dcs0548] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0549.hex dcs0549] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0550.hex dcs0550] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0551.hex dcs0551] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0552.hex dcs0552] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0553.hex dcs0553] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0554.hex dcs0554] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0555.hex dcs0555] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0556.hex dcs0556] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0557.hex dcs0557] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0558.hex dcs0558] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0559.hex dcs0559] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0560.hex dcs0560] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0561.hex dcs0561] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0562.hex dcs0562] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0563.hex dcs0563] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0564.hex dcs0564] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0565.hex dcs0565] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0566.hex dcs0566] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0567.hex dcs0567] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0568.hex dcs0568] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0569.hex dcs0569] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0570.hex dcs0570] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0571.hex dcs0571] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0572.hex dcs0572] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0573.hex dcs0573] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0574.hex dcs0574] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0575.hex dcs0575] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0576.hex dcs0576] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0577.hex dcs0577] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0578.hex dcs0578] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0579.hex dcs0579] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0580.hex dcs0580] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0581.hex dcs0581] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0582.hex dcs0582] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0583.hex dcs0583] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0584.hex dcs0584] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0585.hex dcs0585] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0586.hex dcs0586] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0587.hex dcs0587] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0588.hex dcs0588] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0589.hex dcs0589] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0590.hex dcs0590] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0591.hex dcs0591] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0592.hex dcs0592] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0593.hex dcs0593] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0594.hex dcs0594] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0595.hex dcs0595] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0596.hex dcs0596] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0597.hex dcs0597] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0598.hex dcs0598] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0599.hex dcs0599] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0600.hex dcs0600] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0601.hex dcs0601] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0602.hex dcs0602] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0603.hex dcs0603] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0604.hex dcs0604] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0605.hex dcs0605] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0606.hex dcs0606] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0607.hex dcs0607] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0608.hex dcs0608] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0609.hex dcs0609] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0610.hex dcs0610] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0611.hex dcs0611] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0612.hex dcs0612] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0613.hex dcs0613] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0614.hex dcs0614] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0615.hex dcs0615] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0616.hex dcs0616] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0617.hex dcs0617] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0618.hex dcs0618] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0619.hex dcs0619] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0620.hex dcs0620] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0621.hex dcs0621] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0622.hex dcs0622] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0623.hex dcs0623] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0624.hex dcs0624] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0625.hex dcs0625] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0626.hex dcs0626] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0627.hex dcs0627] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0628.hex dcs0628] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0629.hex dcs0629] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0630.hex dcs0630] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0631.hex dcs0631] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0632.hex dcs0632] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0633.hex dcs0633] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0634.hex dcs0634] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0635.hex dcs0635] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0636.hex dcs0636] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0637.hex dcs0637] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0638.hex dcs0638] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0639.hex dcs0639] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0640.hex dcs0640] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0641.hex dcs0641] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0642.hex dcs0642] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0643.hex dcs0643] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0644.hex dcs0644] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0645.hex dcs0645] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0646.hex dcs0646] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0647.hex dcs0647] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0648.hex dcs0648] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0649.hex dcs0649] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0650.hex dcs0650] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0651.hex dcs0651] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0652.hex dcs0652] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0653.hex dcs0653] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0654.hex dcs0654] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0655.hex dcs0655] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0656.hex dcs0656] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0657.hex dcs0657] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0658.hex dcs0658] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0659.hex dcs0659] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0660.hex dcs0660] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0661.hex dcs0661] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0662.hex dcs0662] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0663.hex dcs0663] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0664.hex dcs0664] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0665.hex dcs0665] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0666.hex dcs0666] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0667.hex dcs0667] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0668.hex dcs0668] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0669.hex dcs0669] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0670.hex dcs0670] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0671.hex dcs0671] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0672.hex dcs0672] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0673.hex dcs0673] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0674.hex dcs0674] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0675.hex dcs0675] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0676.hex dcs0676] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0677.hex dcs0677] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0678.hex dcs0678] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0679.hex dcs0679] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0680.hex dcs0680] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0681.hex dcs0681] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0682.hex dcs0682] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0683.hex dcs0683] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0684.hex dcs0684] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0685.hex dcs0685] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0686.hex dcs0686] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0687.hex dcs0687] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0688.hex dcs0688] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0689.hex dcs0689] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0690.hex dcs0690] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0691.hex dcs0691] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0692.hex dcs0692] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0693.hex dcs0693] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0694.hex dcs0694] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0695.hex dcs0695] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0696.hex dcs0696] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0697.hex dcs0697] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0698.hex dcs0698] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0699.hex dcs0699] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0700.hex dcs0700] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0701.hex dcs0701] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0702.hex dcs0702] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0703.hex dcs0703] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0704.hex dcs0704] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0705.hex dcs0705] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0706.hex dcs0706] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0707.hex dcs0707] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0708.hex dcs0708] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0709.hex dcs0709] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0710.hex dcs0710] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0711.hex dcs0711] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0712.hex dcs0712] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0713.hex dcs0713] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0714.hex dcs0714] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0715.hex dcs0715] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0716.hex dcs0716] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0717.hex dcs0717] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0718.hex dcs0718] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0719.hex dcs0719] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0720.hex dcs0720] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0721.hex dcs0721] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0722.hex dcs0722] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0723.hex dcs0723] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0724.hex dcs0724] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0725.hex dcs0725] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0726.hex dcs0726] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0727.hex dcs0727] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0728.hex dcs0728] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0729.hex dcs0729] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0730.hex dcs0730] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0731.hex dcs0731] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0732.hex dcs0732] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0733.hex dcs0733] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0734.hex dcs0734] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0735.hex dcs0735] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0736.hex dcs0736] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0737.hex dcs0737] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0738.hex dcs0738] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0739.hex dcs0739] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0740.hex dcs0740] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0741.hex dcs0741] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0742.hex dcs0742] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0743.hex dcs0743] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0744.hex dcs0744] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0745.hex dcs0745] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0746.hex dcs0746] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0747.hex dcs0747] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0748.hex dcs0748] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0749.hex dcs0749] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0750.hex dcs0750] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0751.hex dcs0751] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0752.hex dcs0752] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0753.hex dcs0753] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0754.hex dcs0754] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0755.hex dcs0755] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0756.hex dcs0756] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0757.hex dcs0757] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0758.hex dcs0758] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0759.hex dcs0759] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0760.hex dcs0760] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0761.hex dcs0761] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0762.hex dcs0762] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0763.hex dcs0763] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0764.hex dcs0764] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0765.hex dcs0765] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0766.hex dcs0766] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0767.hex dcs0767] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0768.hex dcs0768] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0769.hex dcs0769] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0770.hex dcs0770] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0771.hex dcs0771] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0772.hex dcs0772] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0773.hex dcs0773] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0774.hex dcs0774] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0775.hex dcs0775] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0776.hex dcs0776] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0777.hex dcs0777] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0778.hex dcs0778] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0779.hex dcs0779] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0780.hex dcs0780] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0781.hex dcs0781] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0782.hex dcs0782] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0783.hex dcs0783] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0784.hex dcs0784] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0785.hex dcs0785] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0786.hex dcs0786] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0787.hex dcs0787] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0788.hex dcs0788] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0789.hex dcs0789] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0790.hex dcs0790] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0791.hex dcs0791] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0792.hex dcs0792] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0793.hex dcs0793] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0794.hex dcs0794] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0795.hex dcs0795] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0796.hex dcs0796] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0797.hex dcs0797] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0798.hex dcs0798] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0799.hex dcs0799] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0800.hex dcs0800] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0801.hex dcs0801] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0802.hex dcs0802] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0803.hex dcs0803] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0804.hex dcs0804] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0805.hex dcs0805] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0806.hex dcs0806] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0807.hex dcs0807] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0808.hex dcs0808] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0809.hex dcs0809] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0810.hex dcs0810] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0811.hex dcs0811] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0812.hex dcs0812] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0813.hex dcs0813] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0814.hex dcs0814] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0815.hex dcs0815] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0816.hex dcs0816] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0817.hex dcs0817] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0818.hex dcs0818] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0819.hex dcs0819] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0820.hex dcs0820] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0821.hex dcs0821] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0822.hex dcs0822] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0823.hex dcs0823] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0824.hex dcs0824] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0825.hex dcs0825] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0826.hex dcs0826] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0827.hex dcs0827] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0828.hex dcs0828] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0829.hex dcs0829] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0830.hex dcs0830] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0831.hex dcs0831] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0832.hex dcs0832] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0833.hex dcs0833] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0834.hex dcs0834] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0835.hex dcs0835] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0836.hex dcs0836] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0837.hex dcs0837] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0838.hex dcs0838] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0839.hex dcs0839] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0840.hex dcs0840] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0841.hex dcs0841] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0842.hex dcs0842] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0843.hex dcs0843] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0844.hex dcs0844] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0845.hex dcs0845] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0846.hex dcs0846] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0847.hex dcs0847] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0848.hex dcs0848] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0849.hex dcs0849] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0850.hex dcs0850] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0851.hex dcs0851] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0852.hex dcs0852] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0853.hex dcs0853] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0854.hex dcs0854] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0855.hex dcs0855] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0856.hex dcs0856] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0857.hex dcs0857] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0858.hex dcs0858] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0859.hex dcs0859] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0860.hex dcs0860] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0861.hex dcs0861] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0862.hex dcs0862] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0863.hex dcs0863] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0864.hex dcs0864] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0865.hex dcs0865] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0866.hex dcs0866] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0867.hex dcs0867] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0868.hex dcs0868] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0869.hex dcs0869] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0870.hex dcs0870] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0871.hex dcs0871] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0872.hex dcs0872] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0873.hex dcs0873] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0874.hex dcs0874] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0875.hex dcs0875] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0876.hex dcs0876] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0877.hex dcs0877] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0878.hex dcs0878] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0879.hex dcs0879] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0880.hex dcs0880] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0881.hex dcs0881] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0882.hex dcs0882] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0883.hex dcs0883] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0884.hex dcs0884] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0885.hex dcs0885] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0886.hex dcs0886] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0887.hex dcs0887] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0888.hex dcs0888] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0889.hex dcs0889] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0890.hex dcs0890] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0891.hex dcs0891] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0892.hex dcs0892] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0893.hex dcs0893] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0894.hex dcs0894] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0895.hex dcs0895] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0896.hex dcs0896] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0897.hex dcs0897] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0898.hex dcs0898] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0899.hex dcs0899] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0900.hex dcs0900] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0901.hex dcs0901] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0902.hex dcs0902] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0903.hex dcs0903] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0904.hex dcs0904] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0905.hex dcs0905] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0906.hex dcs0906] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0907.hex dcs0907] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0908.hex dcs0908] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0909.hex dcs0909] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0910.hex dcs0910] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0911.hex dcs0911] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0912.hex dcs0912] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0913.hex dcs0913] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0914.hex dcs0914] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0915.hex dcs0915] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0916.hex dcs0916] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0917.hex dcs0917] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0918.hex dcs0918] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0919.hex dcs0919] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0920.hex dcs0920] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0921.hex dcs0921] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0922.hex dcs0922] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0923.hex dcs0923] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0924.hex dcs0924] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0925.hex dcs0925] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0926.hex dcs0926] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0927.hex dcs0927] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0928.hex dcs0928] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0929.hex dcs0929] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0930.hex dcs0930] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0931.hex dcs0931] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0932.hex dcs0932] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0933.hex dcs0933] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0934.hex dcs0934] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0935.hex dcs0935] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0936.hex dcs0936] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0937.hex dcs0937] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0938.hex dcs0938] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0939.hex dcs0939] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0940.hex dcs0940] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0941.hex dcs0941] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0942.hex dcs0942] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0943.hex dcs0943] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0944.hex dcs0944] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0945.hex dcs0945] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0946.hex dcs0946] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0947.hex dcs0947] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0948.hex dcs0948] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0949.hex dcs0949] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0950.hex dcs0950] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0951.hex dcs0951] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0952.hex dcs0952] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0953.hex dcs0953] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0954.hex dcs0954] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0955.hex dcs0955] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0956.hex dcs0956] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0957.hex dcs0957] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0958.hex dcs0958] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0959.hex dcs0959] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0960.hex dcs0960] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0961.hex dcs0961] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0962.hex dcs0962] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0963.hex dcs0963] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0964.hex dcs0964] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0965.hex dcs0965] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0966.hex dcs0966] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0967.hex dcs0967] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0968.hex dcs0968] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0969.hex dcs0969] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0970.hex dcs0970] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0971.hex dcs0971] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0972.hex dcs0972] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0973.hex dcs0973] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0974.hex dcs0974] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0975.hex dcs0975] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0976.hex dcs0976] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0977.hex dcs0977] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0978.hex dcs0978] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0979.hex dcs0979] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0980.hex dcs0980] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0981.hex dcs0981] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0982.hex dcs0982] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0983.hex dcs0983] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0984.hex dcs0984] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0985.hex dcs0985] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0986.hex dcs0986] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0987.hex dcs0987] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0988.hex dcs0988] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0989.hex dcs0989] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0990.hex dcs0990] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0991.hex dcs0991] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0992.hex dcs0992] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0993.hex dcs0993] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0994.hex dcs0994] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0995.hex dcs0995] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0996.hex dcs0996] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0997.hex dcs0997] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0998.hex dcs0998] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0999.hex dcs0999] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1000.hex dcs1000] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1001.hex dcs1001] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1002.hex dcs1002] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1003.hex dcs1003] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1004.hex dcs1004] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1005.hex dcs1005] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1006.hex dcs1006] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1007.hex dcs1007] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1008.hex dcs1008] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1009.hex dcs1009] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1010.hex dcs1010] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1011.hex dcs1011] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1012.hex dcs1012] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1013.hex dcs1013] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1014.hex dcs1014] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1015.hex dcs1015] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1016.hex dcs1016] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1017.hex dcs1017] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1018.hex dcs1018] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1019.hex dcs1019] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1020.hex dcs1020] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1021.hex dcs1021] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1022.hex dcs1022] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1023.hex dcs1023] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1024.hex dcs1024] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1025.hex dcs1025] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1026.hex dcs1026] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1027.hex dcs1027] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1028.hex dcs1028] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1029.hex dcs1029] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1030.hex dcs1030] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1031.hex dcs1031] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1032.hex dcs1032] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1033.hex dcs1033] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1034.hex dcs1034] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1035.hex dcs1035] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1036.hex dcs1036] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1037.hex dcs1037] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1038.hex dcs1038] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1039.hex dcs1039] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1040.hex dcs1040] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1041.hex dcs1041] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1042.hex dcs1042] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1043.hex dcs1043] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1044.hex dcs1044] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1045.hex dcs1045] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1046.hex dcs1046] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1047.hex dcs1047] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1048.hex dcs1048] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1049.hex dcs1049] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1050.hex dcs1050] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1051.hex dcs1051] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1052.hex dcs1052] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1053.hex dcs1053] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1054.hex dcs1054] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1055.hex dcs1055] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1056.hex dcs1056] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1057.hex dcs1057] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1058.hex dcs1058] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1059.hex dcs1059] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1060.hex dcs1060] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1061.hex dcs1061] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1062.hex dcs1062] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1063.hex dcs1063] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1064.hex dcs1064] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1065.hex dcs1065] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1066.hex dcs1066] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1067.hex dcs1067] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1068.hex dcs1068] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1069.hex dcs1069] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1070.hex dcs1070] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1071.hex dcs1071] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1072.hex dcs1072] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1073.hex dcs1073] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1074.hex dcs1074] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1075.hex dcs1075] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1076.hex dcs1076] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1077.hex dcs1077] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1078.hex dcs1078] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1079.hex dcs1079] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1080.hex dcs1080] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1081.hex dcs1081] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1082.hex dcs1082] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1083.hex dcs1083] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1084.hex dcs1084] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1085.hex dcs1085] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1086.hex dcs1086] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1087.hex dcs1087] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1088.hex dcs1088] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1089.hex dcs1089] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1090.hex dcs1090] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1091.hex dcs1091] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1092.hex dcs1092] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1093.hex dcs1093] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1094.hex dcs1094] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1095.hex dcs1095] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1096.hex dcs1096] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1097.hex dcs1097] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1098.hex dcs1098] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1099.hex dcs1099] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1100.hex dcs1100] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1101.hex dcs1101] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1102.hex dcs1102] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1103.hex dcs1103] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1104.hex dcs1104] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1105.hex dcs1105] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1106.hex dcs1106] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1107.hex dcs1107] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1108.hex dcs1108] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1109.hex dcs1109] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1110.hex dcs1110] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1111.hex dcs1111] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1112.hex dcs1112] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1113.hex dcs1113] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1114.hex dcs1114] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1115.hex dcs1115] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1116.hex dcs1116] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1117.hex dcs1117] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1118.hex dcs1118] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1119.hex dcs1119] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1120.hex dcs1120] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1121.hex dcs1121] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1122.hex dcs1122] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1123.hex dcs1123] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1124.hex dcs1124] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1125.hex dcs1125] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1126.hex dcs1126] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1127.hex dcs1127] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1128.hex dcs1128] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1129.hex dcs1129] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1130.hex dcs1130] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1131.hex dcs1131] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1132.hex dcs1132] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1133.hex dcs1133] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1134.hex dcs1134] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1135.hex dcs1135] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1136.hex dcs1136] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1137.hex dcs1137] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1138.hex dcs1138] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1139.hex dcs1139] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1140.hex dcs1140] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1141.hex dcs1141] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1142.hex dcs1142] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1143.hex dcs1143] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1144.hex dcs1144] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1145.hex dcs1145] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1146.hex dcs1146] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1147.hex dcs1147] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1148.hex dcs1148] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1149.hex dcs1149] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1150.hex dcs1150] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1151.hex dcs1151] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1152.hex dcs1152] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1153.hex dcs1153] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1154.hex dcs1154] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1155.hex dcs1155] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1156.hex dcs1156] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1157.hex dcs1157] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1158.hex dcs1158] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1159.hex dcs1159] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1160.hex dcs1160] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1161.hex dcs1161] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1162.hex dcs1162] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1163.hex dcs1163] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1164.hex dcs1164] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1165.hex dcs1165] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1166.hex dcs1166] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1167.hex dcs1167] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1168.hex dcs1168] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1169.hex dcs1169] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1170.hex dcs1170] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1171.hex dcs1171] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1172.hex dcs1172] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1173.hex dcs1173] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1174.hex dcs1174] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1175.hex dcs1175] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1176.hex dcs1176] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1177.hex dcs1177] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1178.hex dcs1178] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1179.hex dcs1179] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1180.hex dcs1180] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1181.hex dcs1181] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1182.hex dcs1182] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1183.hex dcs1183] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1184.hex dcs1184] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1185.hex dcs1185] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1186.hex dcs1186] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1187.hex dcs1187] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1188.hex dcs1188] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1189.hex dcs1189] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1190.hex dcs1190] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1191.hex dcs1191] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1192.hex dcs1192] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1193.hex dcs1193] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1194.hex dcs1194] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1195.hex dcs1195] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1196.hex dcs1196] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1197.hex dcs1197] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1198.hex dcs1198] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1199.hex dcs1199] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1200.hex dcs1200] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1201.hex dcs1201] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1202.hex dcs1202] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1203.hex dcs1203] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1204.hex dcs1204] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1205.hex dcs1205] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1206.hex dcs1206] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1207.hex dcs1207] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1208.hex dcs1208] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1209.hex dcs1209] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1210.hex dcs1210] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1211.hex dcs1211] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1212.hex dcs1212] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1213.hex dcs1213] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1214.hex dcs1214] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1215.hex dcs1215] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1216.hex dcs1216] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1217.hex dcs1217] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1218.hex dcs1218] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1219.hex dcs1219] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1220.hex dcs1220] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1221.hex dcs1221] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1222.hex dcs1222] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1223.hex dcs1223] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1224.hex dcs1224] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1225.hex dcs1225] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1226.hex dcs1226] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1227.hex dcs1227] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1228.hex dcs1228] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1229.hex dcs1229] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1230.hex dcs1230] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1231.hex dcs1231] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1232.hex dcs1232] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1233.hex dcs1233] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1234.hex dcs1234] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1235.hex dcs1235] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1236.hex dcs1236] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1237.hex dcs1237] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1238.hex dcs1238] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1239.hex dcs1239] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1240.hex dcs1240] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1241.hex dcs1241] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1242.hex dcs1242] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1243.hex dcs1243] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1244.hex dcs1244] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1245.hex dcs1245] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1246.hex dcs1246] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1247.hex dcs1247] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1248.hex dcs1248] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1249.hex dcs1249] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1250.hex dcs1250] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1251.hex dcs1251] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1252.hex dcs1252] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1253.hex dcs1253] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1254.hex dcs1254] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1255.hex dcs1255] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1256.hex dcs1256] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1257.hex dcs1257] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1258.hex dcs1258] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1259.hex dcs1259] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1260.hex dcs1260] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1261.hex dcs1261] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1262.hex dcs1262] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1263.hex dcs1263] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1264.hex dcs1264] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1265.hex dcs1265] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1266.hex dcs1266] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1267.hex dcs1267] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1268.hex dcs1268] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1269.hex dcs1269] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1270.hex dcs1270] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1271.hex dcs1271] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1272.hex dcs1272] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1273.hex dcs1273] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1274.hex dcs1274] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1275.hex dcs1275] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1276.hex dcs1276] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1277.hex dcs1277] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1278.hex dcs1278] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1279.hex dcs1279] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1280.hex dcs1280] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1281.hex dcs1281] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1282.hex dcs1282] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1283.hex dcs1283] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1284.hex dcs1284] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1285.hex dcs1285] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1286.hex dcs1286] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1287.hex dcs1287] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1288.hex dcs1288] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1289.hex dcs1289] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1290.hex dcs1290] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1291.hex dcs1291] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1292.hex dcs1292] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1293.hex dcs1293] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1294.hex dcs1294] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1295.hex dcs1295] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1296.hex dcs1296] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1297.hex dcs1297] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1298.hex dcs1298] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1299.hex dcs1299] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1300.hex dcs1300] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1301.hex dcs1301] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1302.hex dcs1302] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1303.hex dcs1303] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1304.hex dcs1304] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1305.hex dcs1305] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1306.hex dcs1306] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1307.hex dcs1307] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1308.hex dcs1308] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1309.hex dcs1309] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1310.hex dcs1310] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1311.hex dcs1311] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1312.hex dcs1312] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1313.hex dcs1313] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1314.hex dcs1314] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1315.hex dcs1315] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1316.hex dcs1316] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1317.hex dcs1317] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1318.hex dcs1318] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1319.hex dcs1319] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1320.hex dcs1320] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1321.hex dcs1321] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1322.hex dcs1322] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1323.hex dcs1323] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1324.hex dcs1324] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1325.hex dcs1325] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1326.hex dcs1326] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1327.hex dcs1327] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1328.hex dcs1328] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1329.hex dcs1329] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1330.hex dcs1330] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1331.hex dcs1331] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1332.hex dcs1332] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1333.hex dcs1333] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1334.hex dcs1334] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1335.hex dcs1335] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1336.hex dcs1336] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1337.hex dcs1337] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1338.hex dcs1338] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1339.hex dcs1339] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1340.hex dcs1340] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1341.hex dcs1341] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1342.hex dcs1342] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1343.hex dcs1343] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1344.hex dcs1344] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1345.hex dcs1345] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1346.hex dcs1346] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1347.hex dcs1347] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1348.hex dcs1348] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1349.hex dcs1349] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1350.hex dcs1350] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1351.hex dcs1351] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1352.hex dcs1352] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1353.hex dcs1353] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1354.hex dcs1354] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1355.hex dcs1355] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1356.hex dcs1356] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1357.hex dcs1357] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1358.hex dcs1358] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1359.hex dcs1359] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1360.hex dcs1360] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1361.hex dcs1361] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1362.hex dcs1362] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1363.hex dcs1363] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1364.hex dcs1364] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1365.hex dcs1365] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1366.hex dcs1366] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1367.hex dcs1367] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1368.hex dcs1368] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1369.hex dcs1369] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1370.hex dcs1370] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1371.hex dcs1371] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1372.hex dcs1372] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1373.hex dcs1373] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1374.hex dcs1374] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1375.hex dcs1375] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1376.hex dcs1376] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1377.hex dcs1377] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1378.hex dcs1378] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1379.hex dcs1379] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1380.hex dcs1380] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1381.hex dcs1381] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1382.hex dcs1382] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1383.hex dcs1383] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1384.hex dcs1384] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1385.hex dcs1385] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1386.hex dcs1386] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1387.hex dcs1387] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1388.hex dcs1388] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1389.hex dcs1389] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1390.hex dcs1390] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1391.hex dcs1391] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1392.hex dcs1392] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1393.hex dcs1393] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1394.hex dcs1394] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1395.hex dcs1395] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1396.hex dcs1396] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1397.hex dcs1397] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1398.hex dcs1398] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1399.hex dcs1399] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1400.hex dcs1400] d7c4467c09c56e28f5b820bc579bdc2ca39aa2c3 0 400 1723 1722 2012-01-30T11:36:10Z Dfe002 7 wikitext text/x-wiki '''30 - 100'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0030.hex dcs0030] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0031.hex dcs0031] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0032.hex dcs0032] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0033.hex dcs0033] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0034.hex dcs0034] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0035.hex dcs0035] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0036.hex dcs0036] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0037.hex dcs0037] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0038.hex dcs0038] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0039.hex dcs0039]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0040.hex dcs0040] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0041.hex dcs0041] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0042.hex dcs0042] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0043.hex dcs0043] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0044.hex dcs0044] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0045.hex dcs0045] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0046.hex dcs0046] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0047.hex dcs0047] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0048.hex dcs0048] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0049.hex dcs0049]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0050.hex dcs0050] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0051.hex dcs0051] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0052.hex dcs0052] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0053.hex dcs0053] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0054.hex dcs0054] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0055.hex dcs0055] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0056.hex dcs0056] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0057.hex dcs0057] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0058.hex dcs0058] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0059.hex dcs0059]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0060.hex dcs0060] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0061.hex dcs0061] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0062.hex dcs0062] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0063.hex dcs0063] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0064.hex dcs0064] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0065.hex dcs0065] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0066.hex dcs0066] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0067.hex dcs0067] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0068.hex dcs0068] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0069.hex dcs0069]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0070.hex dcs0070] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0071.hex dcs0071] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0072.hex dcs0072] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0073.hex dcs0073] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0074.hex dcs0074] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0075.hex dcs0075] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0076.hex dcs0076] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0077.hex dcs0077] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0078.hex dcs0078] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0079.hex dcs0079]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0080.hex dcs0080] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0081.hex dcs0081] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0082.hex dcs0082] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0083.hex dcs0083] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0084.hex dcs0084] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0085.hex dcs0085] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0086.hex dcs0086] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0087.hex dcs0087] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0088.hex dcs0088] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0089.hex dcs0089]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0090.hex dcs0090] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0091.hex dcs0091] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0092.hex dcs0092] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0093.hex dcs0093] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0094.hex dcs0094] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0095.hex dcs0095] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0096.hex dcs0096] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0097.hex dcs0097] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0098.hex dcs0098] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0099.hex dcs0099]<br> '''100 - 199'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0100.hex dcs0100] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0101.hex dcs0101] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0102.hex dcs0102] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0103.hex dcs0103] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0104.hex dcs0104] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0105.hex dcs0105] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0106.hex dcs0106] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0107.hex dcs0107] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0108.hex dcs0108] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0109.hex dcs0109]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0110.hex dcs0110] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0111.hex dcs0111] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0112.hex dcs0112] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0113.hex dcs0113] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0114.hex dcs0114] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0115.hex dcs0115] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0116.hex dcs0116] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0117.hex dcs0117] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0118.hex dcs0118] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0119.hex dcs0119]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0120.hex dcs0120] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0121.hex dcs0121] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0122.hex dcs0122] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0123.hex dcs0123] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0124.hex dcs0124] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0125.hex dcs0125] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0126.hex dcs0126] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0127.hex dcs0127] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0128.hex dcs0128] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0129.hex dcs0129]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0130.hex dcs0130] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0131.hex dcs0131] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0132.hex dcs0132] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0133.hex dcs0133] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0134.hex dcs0134] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0135.hex dcs0135] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0136.hex dcs0136] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0137.hex dcs0137] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0138.hex dcs0138] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0139.hex dcs0139]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0140.hex dcs0140] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0141.hex dcs0141] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0142.hex dcs0142] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0143.hex dcs0143] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0144.hex dcs0144] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0145.hex dcs0145] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0146.hex dcs0146] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0147.hex dcs0147] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0148.hex dcs0148] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0149.hex dcs0149]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0150.hex dcs0150] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0151.hex dcs0151] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0152.hex dcs0152] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0153.hex dcs0153] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0154.hex dcs0154] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0155.hex dcs0155] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0156.hex dcs0156] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0157.hex dcs0157] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0158.hex dcs0158] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0159.hex dcs0159]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0160.hex dcs0160] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0161.hex dcs0161] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0162.hex dcs0162] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0163.hex dcs0163] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0164.hex dcs0164] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0165.hex dcs0165] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0166.hex dcs0166] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0167.hex dcs0167] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0168.hex dcs0168] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0169.hex dcs0169]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0170.hex dcs0170] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0171.hex dcs0171] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0172.hex dcs0172] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0173.hex dcs0173] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0174.hex dcs0174] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0175.hex dcs0175] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0176.hex dcs0176] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0177.hex dcs0177] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0178.hex dcs0178] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0179.hex dcs0179]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0180.hex dcs0180] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0181.hex dcs0181] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0182.hex dcs0182] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0183.hex dcs0183] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0184.hex dcs0184] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0185.hex dcs0185] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0186.hex dcs0186] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0187.hex dcs0187] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0188.hex dcs0188] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0189.hex dcs0189]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0190.hex dcs0190] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0191.hex dcs0191] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0192.hex dcs0192] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0193.hex dcs0193] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0194.hex dcs0194] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0195.hex dcs0195] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0196.hex dcs0196] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0197.hex dcs0197] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0198.hex dcs0198] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0199.hex dcs0199]<br> '''200 - 299'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0200.hex dcs0200] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0201.hex dcs0201] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0202.hex dcs0202] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0203.hex dcs0203] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0204.hex dcs0204] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0205.hex dcs0205] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0206.hex dcs0206] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0207.hex dcs0207] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0208.hex dcs0208] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0209.hex dcs0209]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0210.hex dcs0210] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0211.hex dcs0211] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0212.hex dcs0212] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0213.hex dcs0213] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0214.hex dcs0214] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0215.hex dcs0215] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0216.hex dcs0216] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0217.hex dcs0217] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0218.hex dcs0218] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0219.hex dcs0219]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0220.hex dcs0220] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0221.hex dcs0221] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0222.hex dcs0222] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0223.hex dcs0223] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0224.hex dcs0224] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0225.hex dcs0225] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0226.hex dcs0226] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0227.hex dcs0227] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0228.hex dcs0228] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0229.hex dcs0229]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0230.hex dcs0230] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0231.hex dcs0231] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0232.hex dcs0232] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0233.hex dcs0233] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0234.hex dcs0234] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0235.hex dcs0235] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0236.hex dcs0236] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0237.hex dcs0237] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0238.hex dcs0238] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0239.hex dcs0239]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0240.hex dcs0240] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0241.hex dcs0241] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0242.hex dcs0242] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0243.hex dcs0243] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0244.hex dcs0244] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0245.hex dcs0245] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0246.hex dcs0246] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0247.hex dcs0247] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0248.hex dcs0248] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0249.hex dcs0249]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0250.hex dcs0250] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0251.hex dcs0251] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0252.hex dcs0252] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0253.hex dcs0253] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0254.hex dcs0254] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0255.hex dcs0255] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0256.hex dcs0256] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0257.hex dcs0257] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0258.hex dcs0258] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0259.hex dcs0259]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0260.hex dcs0260] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0261.hex dcs0261] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0262.hex dcs0262] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0263.hex dcs0263] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0264.hex dcs0264] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0265.hex dcs0265] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0266.hex dcs0266] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0267.hex dcs0267] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0268.hex dcs0268] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0269.hex dcs0269]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0270.hex dcs0270] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0271.hex dcs0271] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0272.hex dcs0272] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0273.hex dcs0273] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0274.hex dcs0274] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0275.hex dcs0275] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0276.hex dcs0276] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0277.hex dcs0277] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0278.hex dcs0278] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0279.hex dcs0279]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0280.hex dcs0280] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0281.hex dcs0281] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0282.hex dcs0282] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0283.hex dcs0283] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0284.hex dcs0284] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0285.hex dcs0285] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0286.hex dcs0286] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0287.hex dcs0287] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0288.hex dcs0288] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0289.hex dcs0289]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0290.hex dcs0290] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0291.hex dcs0291] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0292.hex dcs0292] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0293.hex dcs0293] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0294.hex dcs0294] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0295.hex dcs0295] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0296.hex dcs0296] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0297.hex dcs0297] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0298.hex dcs0298] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0299.hex dcs0299]<br> '''300 - 399'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0300.hex dcs0300] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0301.hex dcs0301] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0302.hex dcs0302] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0303.hex dcs0303] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0304.hex dcs0304] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0305.hex dcs0305] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0306.hex dcs0306] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0307.hex dcs0307] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0308.hex dcs0308] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0309.hex dcs0309]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0310.hex dcs0310] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0311.hex dcs0311] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0312.hex dcs0312] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0313.hex dcs0313] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0314.hex dcs0314] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0315.hex dcs0315] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0316.hex dcs0316] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0317.hex dcs0317] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0318.hex dcs0318] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0319.hex dcs0319]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0320.hex dcs0320] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0321.hex dcs0321] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0322.hex dcs0322] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0323.hex dcs0323] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0324.hex dcs0324] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0325.hex dcs0325] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0326.hex dcs0326] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0327.hex dcs0327] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0328.hex dcs0328] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0329.hex dcs0329]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0330.hex dcs0330] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0331.hex dcs0331] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0332.hex dcs0332] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0333.hex dcs0333] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0334.hex dcs0334] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0335.hex dcs0335] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0336.hex dcs0336] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0337.hex dcs0337] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0338.hex dcs0338] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0339.hex dcs0339]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0340.hex dcs0340] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0341.hex dcs0341] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0342.hex dcs0342] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0343.hex dcs0343] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0344.hex dcs0344] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0345.hex dcs0345] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0346.hex dcs0346] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0347.hex dcs0347] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0348.hex dcs0348] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0349.hex dcs0349]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0350.hex dcs0350] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0351.hex dcs0351] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0352.hex dcs0352] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0353.hex dcs0353] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0354.hex dcs0354] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0355.hex dcs0355] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0356.hex dcs0356] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0357.hex dcs0357] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0358.hex dcs0358] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0359.hex dcs0359]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0360.hex dcs0360] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0361.hex dcs0361] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0362.hex dcs0362] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0363.hex dcs0363] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0364.hex dcs0364] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0365.hex dcs0365] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0366.hex dcs0366] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0367.hex dcs0367] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0368.hex dcs0368] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0369.hex dcs0369]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0370.hex dcs0370] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0371.hex dcs0371] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0372.hex dcs0372] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0373.hex dcs0373] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0374.hex dcs0374] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0375.hex dcs0375] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0376.hex dcs0376] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0377.hex dcs0377] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0378.hex dcs0378] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0379.hex dcs0379]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0380.hex dcs0380] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0381.hex dcs0381] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0382.hex dcs0382] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0383.hex dcs0383] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0384.hex dcs0384] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0385.hex dcs0385] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0386.hex dcs0386] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0387.hex dcs0387] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0388.hex dcs0388] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0389.hex dcs0389]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0390.hex dcs0390] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0391.hex dcs0391] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0392.hex dcs0392] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0393.hex dcs0393] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0394.hex dcs0394] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0395.hex dcs0395] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0396.hex dcs0396] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0397.hex dcs0397] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0398.hex dcs0398] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0399.hex dcs0399]<br> '''400 - 499'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0400.hex dcs0400] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0401.hex dcs0401] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0402.hex dcs0402] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0403.hex dcs0403] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0404.hex dcs0404] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0405.hex dcs0405] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0406.hex dcs0406] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0407.hex dcs0407] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0408.hex dcs0408] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0409.hex dcs0409]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0410.hex dcs0410] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0411.hex dcs0411] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0412.hex dcs0412] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0413.hex dcs0413] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0414.hex dcs0414] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0415.hex dcs0415] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0416.hex dcs0416] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0417.hex dcs0417] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0418.hex dcs0418] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0419.hex dcs0419]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0420.hex dcs0420] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0421.hex dcs0421] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0422.hex dcs0422] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0423.hex dcs0423] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0424.hex dcs0424] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0425.hex dcs0425] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0426.hex dcs0426] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0427.hex dcs0427] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0428.hex dcs0428] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0429.hex dcs0429]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0430.hex dcs0430] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0431.hex dcs0431] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0432.hex dcs0432] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0433.hex dcs0433] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0434.hex dcs0434] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0435.hex dcs0435] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0436.hex dcs0436] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0437.hex dcs0437] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0438.hex dcs0438] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0439.hex dcs0439]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0440.hex dcs0440] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0441.hex dcs0441] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0442.hex dcs0442] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0443.hex dcs0443] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0444.hex dcs0444] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0445.hex dcs0445] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0446.hex dcs0446] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0447.hex dcs0447] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0448.hex dcs0448] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0449.hex dcs0449]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0450.hex dcs0450] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0451.hex dcs0451] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0452.hex dcs0452] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0453.hex dcs0453] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0454.hex dcs0454] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0455.hex dcs0455] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0456.hex dcs0456] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0457.hex dcs0457] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0458.hex dcs0458] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0459.hex dcs0459]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0460.hex dcs0460] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0461.hex dcs0461] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0462.hex dcs0462] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0463.hex dcs0463] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0464.hex dcs0464] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0465.hex dcs0465] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0466.hex dcs0466] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0467.hex dcs0467] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0468.hex dcs0468] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0469.hex dcs0469]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0470.hex dcs0470] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0471.hex dcs0471] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0472.hex dcs0472] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0473.hex dcs0473] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0474.hex dcs0474] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0475.hex dcs0475] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0476.hex dcs0476] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0477.hex dcs0477] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0478.hex dcs0478] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0479.hex dcs0479]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0480.hex dcs0480] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0481.hex dcs0481] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0482.hex dcs0482] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0483.hex dcs0483] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0484.hex dcs0484] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0485.hex dcs0485] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0486.hex dcs0486] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0487.hex dcs0487] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0488.hex dcs0488] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0489.hex dcs0489]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0490.hex dcs0490] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0491.hex dcs0491] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0492.hex dcs0492] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0493.hex dcs0493] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0494.hex dcs0494] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0495.hex dcs0495] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0496.hex dcs0496] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0497.hex dcs0497] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0498.hex dcs0498] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0499.hex dcs0499]<br> '''500 - 599'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0500.hex dcs0500] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0501.hex dcs0501] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0502.hex dcs0502] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0503.hex dcs0503] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0504.hex dcs0504] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0505.hex dcs0505] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0506.hex dcs0506] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0507.hex dcs0507] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0508.hex dcs0508] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0509.hex dcs0509]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0510.hex dcs0510] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0511.hex dcs0511] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0512.hex dcs0512] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0513.hex dcs0513] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0514.hex dcs0514] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0515.hex dcs0515] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0516.hex dcs0516] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0517.hex dcs0517] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0518.hex dcs0518] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0519.hex dcs0519]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0520.hex dcs0520] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0521.hex dcs0521] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0522.hex dcs0522] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0523.hex dcs0523] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0524.hex dcs0524] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0525.hex dcs0525] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0526.hex dcs0526] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0527.hex dcs0527] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0528.hex dcs0528] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0529.hex dcs0529]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0530.hex dcs0530] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0531.hex dcs0531] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0532.hex dcs0532] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0533.hex dcs0533] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0534.hex dcs0534] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0535.hex dcs0535] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0536.hex dcs0536] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0537.hex dcs0537] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0538.hex dcs0538] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0539.hex dcs0539]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0540.hex dcs0540] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0541.hex dcs0541] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0542.hex dcs0542] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0543.hex dcs0543] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0544.hex dcs0544] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0545.hex dcs0545] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0546.hex dcs0546] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0547.hex dcs0547] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0548.hex dcs0548] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0549.hex dcs0549]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0550.hex dcs0550] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0551.hex dcs0551] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0552.hex dcs0552] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0553.hex dcs0553] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0554.hex dcs0554] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0555.hex dcs0555] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0556.hex dcs0556] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0557.hex dcs0557] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0558.hex dcs0558] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0559.hex dcs0559]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0560.hex dcs0560] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0561.hex dcs0561] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0562.hex dcs0562] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0563.hex dcs0563] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0564.hex dcs0564] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0565.hex dcs0565] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0566.hex dcs0566] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0567.hex dcs0567] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0568.hex dcs0568] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0569.hex dcs0569]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0570.hex dcs0570] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0571.hex dcs0571] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0572.hex dcs0572] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0573.hex dcs0573] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0574.hex dcs0574] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0575.hex dcs0575] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0576.hex dcs0576] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0577.hex dcs0577] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0578.hex dcs0578] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0579.hex dcs0579]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0580.hex dcs0580] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0581.hex dcs0581] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0582.hex dcs0582] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0583.hex dcs0583] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0584.hex dcs0584] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0585.hex dcs0585] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0586.hex dcs0586] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0587.hex dcs0587] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0588.hex dcs0588] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0589.hex dcs0589]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0590.hex dcs0590] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0591.hex dcs0591] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0592.hex dcs0592] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0593.hex dcs0593] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0594.hex dcs0594] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0595.hex dcs0595] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0596.hex dcs0596] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0597.hex dcs0597] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0598.hex dcs0598] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0599.hex dcs0599]<br> '''600 - 699'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0600.hex dcs0600] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0601.hex dcs0601] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0602.hex dcs0602] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0603.hex dcs0603] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0604.hex dcs0604] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0605.hex dcs0605] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0606.hex dcs0606] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0607.hex dcs0607] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0608.hex dcs0608] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0609.hex dcs0609]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0610.hex dcs0610] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0611.hex dcs0611] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0612.hex dcs0612] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0613.hex dcs0613] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0614.hex dcs0614] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0615.hex dcs0615] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0616.hex dcs0616] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0617.hex dcs0617] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0618.hex dcs0618] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0619.hex dcs0619]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0620.hex dcs0620] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0621.hex dcs0621] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0622.hex dcs0622] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0623.hex dcs0623] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0624.hex dcs0624] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0625.hex dcs0625] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0626.hex dcs0626] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0627.hex dcs0627] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0628.hex dcs0628] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0629.hex dcs0629]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0630.hex dcs0630] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0631.hex dcs0631] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0632.hex dcs0632] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0633.hex dcs0633] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0634.hex dcs0634] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0635.hex dcs0635] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0636.hex dcs0636] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0637.hex dcs0637] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0638.hex dcs0638] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0639.hex dcs0639]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0640.hex dcs0640] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0641.hex dcs0641] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0642.hex dcs0642] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0643.hex dcs0643] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0644.hex dcs0644] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0645.hex dcs0645] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0646.hex dcs0646] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0647.hex dcs0647] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0648.hex dcs0648] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0649.hex dcs0649]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0650.hex dcs0650] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0651.hex dcs0651] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0652.hex dcs0652] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0653.hex dcs0653] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0654.hex dcs0654] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0655.hex dcs0655] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0656.hex dcs0656] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0657.hex dcs0657] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0658.hex dcs0658] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0659.hex dcs0659]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0660.hex dcs0660] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0661.hex dcs0661] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0662.hex dcs0662] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0663.hex dcs0663] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0664.hex dcs0664] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0665.hex dcs0665] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0666.hex dcs0666] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0667.hex dcs0667] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0668.hex dcs0668] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0669.hex dcs0669]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0670.hex dcs0670] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0671.hex dcs0671] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0672.hex dcs0672] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0673.hex dcs0673] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0674.hex dcs0674] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0675.hex dcs0675] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0676.hex dcs0676] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0677.hex dcs0677] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0678.hex dcs0678] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0679.hex dcs0679]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0680.hex dcs0680] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0681.hex dcs0681] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0682.hex dcs0682] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0683.hex dcs0683] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0684.hex dcs0684] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0685.hex dcs0685] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0686.hex dcs0686] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0687.hex dcs0687] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0688.hex dcs0688] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0689.hex dcs0689]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0690.hex dcs0690] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0691.hex dcs0691] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0692.hex dcs0692] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0693.hex dcs0693] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0694.hex dcs0694] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0695.hex dcs0695] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0696.hex dcs0696] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0697.hex dcs0697] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0698.hex dcs0698] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0699.hex dcs0699]<br> '''700 - 799'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0700.hex dcs0700] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0701.hex dcs0701] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0702.hex dcs0702] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0703.hex dcs0703] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0704.hex dcs0704] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0705.hex dcs0705] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0706.hex dcs0706] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0707.hex dcs0707] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0708.hex dcs0708] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0709.hex dcs0709]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0710.hex dcs0710] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0711.hex dcs0711] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0712.hex dcs0712] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0713.hex dcs0713] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0714.hex dcs0714] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0715.hex dcs0715] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0716.hex dcs0716] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0717.hex dcs0717] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0718.hex dcs0718] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0719.hex dcs0719]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0720.hex dcs0720] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0721.hex dcs0721] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0722.hex dcs0722] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0723.hex dcs0723] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0724.hex dcs0724] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0725.hex dcs0725] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0726.hex dcs0726] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0727.hex dcs0727] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0728.hex dcs0728] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0729.hex dcs0729]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0730.hex dcs0730] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0731.hex dcs0731] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0732.hex dcs0732] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0733.hex dcs0733] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0734.hex dcs0734] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0735.hex dcs0735] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0736.hex dcs0736] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0737.hex dcs0737] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0738.hex dcs0738] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0739.hex dcs0739]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0740.hex dcs0740] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0741.hex dcs0741] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0742.hex dcs0742] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0743.hex dcs0743] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0744.hex dcs0744] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0745.hex dcs0745] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0746.hex dcs0746] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0747.hex dcs0747] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0748.hex dcs0748] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0749.hex dcs0749]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0750.hex dcs0750] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0751.hex dcs0751] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0752.hex dcs0752] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0753.hex dcs0753] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0754.hex dcs0754] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0755.hex dcs0755] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0756.hex dcs0756] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0757.hex dcs0757] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0758.hex dcs0758] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0759.hex dcs0759]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0760.hex dcs0760] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0761.hex dcs0761] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0762.hex dcs0762] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0763.hex dcs0763] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0764.hex dcs0764] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0765.hex dcs0765] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0766.hex dcs0766] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0767.hex dcs0767] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0768.hex dcs0768] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0769.hex dcs0769]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0770.hex dcs0770] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0771.hex dcs0771] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0772.hex dcs0772] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0773.hex dcs0773] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0774.hex dcs0774] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0775.hex dcs0775] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0776.hex dcs0776] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0777.hex dcs0777] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0778.hex dcs0778] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0779.hex dcs0779]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0780.hex dcs0780] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0781.hex dcs0781] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0782.hex dcs0782] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0783.hex dcs0783] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0784.hex dcs0784] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0785.hex dcs0785] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0786.hex dcs0786] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0787.hex dcs0787] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0788.hex dcs0788] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0789.hex dcs0789]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0790.hex dcs0790] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0791.hex dcs0791] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0792.hex dcs0792] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0793.hex dcs0793] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0794.hex dcs0794] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0795.hex dcs0795] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0796.hex dcs0796] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0797.hex dcs0797] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0798.hex dcs0798] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0799.hex dcs0799]<br> '''800 - 899'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0800.hex dcs0800] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0801.hex dcs0801] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0802.hex dcs0802] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0803.hex dcs0803] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0804.hex dcs0804] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0805.hex dcs0805] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0806.hex dcs0806] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0807.hex dcs0807] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0808.hex dcs0808] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0809.hex dcs0809]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0810.hex dcs0810] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0811.hex dcs0811] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0812.hex dcs0812] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0813.hex dcs0813] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0814.hex dcs0814] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0815.hex dcs0815] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0816.hex dcs0816] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0817.hex dcs0817] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0818.hex dcs0818] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0819.hex dcs0819]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0820.hex dcs0820] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0821.hex dcs0821] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0822.hex dcs0822] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0823.hex dcs0823] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0824.hex dcs0824] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0825.hex dcs0825] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0826.hex dcs0826] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0827.hex dcs0827] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0828.hex dcs0828] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0829.hex dcs0829]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0830.hex dcs0830] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0831.hex dcs0831] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0832.hex dcs0832] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0833.hex dcs0833] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0834.hex dcs0834] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0835.hex dcs0835] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0836.hex dcs0836] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0837.hex dcs0837] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0838.hex dcs0838] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0839.hex dcs0839]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0840.hex dcs0840] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0841.hex dcs0841] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0842.hex dcs0842] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0843.hex dcs0843] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0844.hex dcs0844] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0845.hex dcs0845] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0846.hex dcs0846] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0847.hex dcs0847] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0848.hex dcs0848] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0849.hex dcs0849]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0850.hex dcs0850] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0851.hex dcs0851] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0852.hex dcs0852] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0853.hex dcs0853] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0854.hex dcs0854] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0855.hex dcs0855] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0856.hex dcs0856] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0857.hex dcs0857] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0858.hex dcs0858] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0859.hex dcs0859]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0860.hex dcs0860] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0861.hex dcs0861] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0862.hex dcs0862] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0863.hex dcs0863] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0864.hex dcs0864] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0865.hex dcs0865] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0866.hex dcs0866] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0867.hex dcs0867] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0868.hex dcs0868] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0869.hex dcs0869]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0870.hex dcs0870] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0871.hex dcs0871] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0872.hex dcs0872] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0873.hex dcs0873] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0874.hex dcs0874] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0875.hex dcs0875] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0876.hex dcs0876] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0877.hex dcs0877] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0878.hex dcs0878] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0879.hex dcs0879]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0880.hex dcs0880] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0881.hex dcs0881] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0882.hex dcs0882] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0883.hex dcs0883] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0884.hex dcs0884] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0885.hex dcs0885] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0886.hex dcs0886] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0887.hex dcs0887] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0888.hex dcs0888] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0889.hex dcs0889]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0890.hex dcs0890] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0891.hex dcs0891] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0892.hex dcs0892] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0893.hex dcs0893] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0894.hex dcs0894] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0895.hex dcs0895] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0896.hex dcs0896] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0897.hex dcs0897] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0898.hex dcs0898] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0899.hex dcs0899]<br> '''900 - 999'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0900.hex dcs0900] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0901.hex dcs0901] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0902.hex dcs0902] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0903.hex dcs0903] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0904.hex dcs0904] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0905.hex dcs0905] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0906.hex dcs0906] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0907.hex dcs0907] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0908.hex dcs0908] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0909.hex dcs0909]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0910.hex dcs0910] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0911.hex dcs0911] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0912.hex dcs0912] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0913.hex dcs0913] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0914.hex dcs0914] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0915.hex dcs0915] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0916.hex dcs0916] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0917.hex dcs0917] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0918.hex dcs0918] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0919.hex dcs0919]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0920.hex dcs0920] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0921.hex dcs0921] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0922.hex dcs0922] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0923.hex dcs0923] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0924.hex dcs0924] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0925.hex dcs0925] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0926.hex dcs0926] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0927.hex dcs0927] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0928.hex dcs0928] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0929.hex dcs0929]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0930.hex dcs0930] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0931.hex dcs0931] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0932.hex dcs0932] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0933.hex dcs0933] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0934.hex dcs0934] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0935.hex dcs0935] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0936.hex dcs0936] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0937.hex dcs0937] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0938.hex dcs0938] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0939.hex dcs0939]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0940.hex dcs0940] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0941.hex dcs0941] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0942.hex dcs0942] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0943.hex dcs0943] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0944.hex dcs0944] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0945.hex dcs0945] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0946.hex dcs0946] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0947.hex dcs0947] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0948.hex dcs0948] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0949.hex dcs0949]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0950.hex dcs0950] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0951.hex dcs0951] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0952.hex dcs0952] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0953.hex dcs0953] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0954.hex dcs0954] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0955.hex dcs0955] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0956.hex dcs0956] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0957.hex dcs0957] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0958.hex dcs0958] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0959.hex dcs0959]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0960.hex dcs0960] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0961.hex dcs0961] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0962.hex dcs0962] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0963.hex dcs0963] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0964.hex dcs0964] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0965.hex dcs0965] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0966.hex dcs0966] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0967.hex dcs0967] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0968.hex dcs0968] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0969.hex dcs0969]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0970.hex dcs0970] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0971.hex dcs0971] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0972.hex dcs0972] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0973.hex dcs0973] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0974.hex dcs0974] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0975.hex dcs0975] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0976.hex dcs0976] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0977.hex dcs0977] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0978.hex dcs0978] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0979.hex dcs0979]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0980.hex dcs0980] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0981.hex dcs0981] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0982.hex dcs0982] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0983.hex dcs0983] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0984.hex dcs0984] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0985.hex dcs0985] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0986.hex dcs0986] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0987.hex dcs0987] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0988.hex dcs0988] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0989.hex dcs0989]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0990.hex dcs0990] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0991.hex dcs0991] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0992.hex dcs0992] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0993.hex dcs0993] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0994.hex dcs0994] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0995.hex dcs0995] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0996.hex dcs0996] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0997.hex dcs0997] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0998.hex dcs0998] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0999.hex dcs0999]<br> '''1000 - 1099'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1000.hex dcs1000] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1001.hex dcs1001] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1002.hex dcs1002] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1003.hex dcs1003] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1004.hex dcs1004] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1005.hex dcs1005] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1006.hex dcs1006] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1007.hex dcs1007] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1008.hex dcs1008] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1009.hex dcs1009]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1010.hex dcs1010] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1011.hex dcs1011] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1012.hex dcs1012] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1013.hex dcs1013] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1014.hex dcs1014] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1015.hex dcs1015] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1016.hex dcs1016] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1017.hex dcs1017] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1018.hex dcs1018] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1019.hex dcs1019]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1020.hex dcs1020] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1021.hex dcs1021] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1022.hex dcs1022] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1023.hex dcs1023] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1024.hex dcs1024] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1025.hex dcs1025] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1026.hex dcs1026] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1027.hex dcs1027] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1028.hex dcs1028] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1029.hex dcs1029]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1030.hex dcs1030] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1031.hex dcs1031] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1032.hex dcs1032] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1033.hex dcs1033] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1034.hex dcs1034] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1035.hex dcs1035] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1036.hex dcs1036] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1037.hex dcs1037] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1038.hex dcs1038] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1039.hex dcs1039]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1040.hex dcs1040] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1041.hex dcs1041] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1042.hex dcs1042] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1043.hex dcs1043] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1044.hex dcs1044] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1045.hex dcs1045] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1046.hex dcs1046] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1047.hex dcs1047] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1048.hex dcs1048] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1049.hex dcs1049]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1050.hex dcs1050] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1051.hex dcs1051] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1052.hex dcs1052] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1053.hex dcs1053] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1054.hex dcs1054] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1055.hex dcs1055] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1056.hex dcs1056] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1057.hex dcs1057] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1058.hex dcs1058] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1059.hex dcs1059]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1060.hex dcs1060] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1061.hex dcs1061] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1062.hex dcs1062] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1063.hex dcs1063] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1064.hex dcs1064] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1065.hex dcs1065] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1066.hex dcs1066] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1067.hex dcs1067] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1068.hex dcs1068] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1069.hex dcs1069]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1070.hex dcs1070] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1071.hex dcs1071] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1072.hex dcs1072] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1073.hex dcs1073] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1074.hex dcs1074] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1075.hex dcs1075] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1076.hex dcs1076] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1077.hex dcs1077] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1078.hex dcs1078] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1079.hex dcs1079]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1080.hex dcs1080] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1081.hex dcs1081] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1082.hex dcs1082] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1083.hex dcs1083] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1084.hex dcs1084] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1085.hex dcs1085] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1086.hex dcs1086] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1087.hex dcs1087] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1088.hex dcs1088] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1089.hex dcs1089]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1090.hex dcs1090] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1091.hex dcs1091] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1092.hex dcs1092] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1093.hex dcs1093] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1094.hex dcs1094] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1095.hex dcs1095] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1096.hex dcs1096] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1097.hex dcs1097] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1098.hex dcs1098] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1099.hex dcs1099]<br> '''1100 - 1199'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1100.hex dcs1100] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1101.hex dcs1101] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1102.hex dcs1102] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1103.hex dcs1103] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1104.hex dcs1104] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1105.hex dcs1105] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1106.hex dcs1106] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1107.hex dcs1107] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1108.hex dcs1108] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1109.hex dcs1109]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1110.hex dcs1110] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1111.hex dcs1111] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1112.hex dcs1112] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1113.hex dcs1113] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1114.hex dcs1114] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1115.hex dcs1115] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1116.hex dcs1116] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1117.hex dcs1117] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1118.hex dcs1118] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1119.hex dcs1119]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1120.hex dcs1120] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1121.hex dcs1121] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1122.hex dcs1122] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1123.hex dcs1123] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1124.hex dcs1124] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1125.hex dcs1125] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1126.hex dcs1126] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1127.hex dcs1127] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1128.hex dcs1128] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1129.hex dcs1129]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1130.hex dcs1130] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1131.hex dcs1131] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1132.hex dcs1132] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1133.hex dcs1133] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1134.hex dcs1134] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1135.hex dcs1135] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1136.hex dcs1136] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1137.hex dcs1137] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1138.hex dcs1138] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1139.hex dcs1139]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1140.hex dcs1140] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1141.hex dcs1141] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1142.hex dcs1142] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1143.hex dcs1143] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1144.hex dcs1144] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1145.hex dcs1145] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1146.hex dcs1146] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1147.hex dcs1147] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1148.hex dcs1148] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1149.hex dcs1149]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1150.hex dcs1150] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1151.hex dcs1151] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1152.hex dcs1152] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1153.hex dcs1153] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1154.hex dcs1154] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1155.hex dcs1155] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1156.hex dcs1156] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1157.hex dcs1157] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1158.hex dcs1158] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1159.hex dcs1159]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1160.hex dcs1160] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1161.hex dcs1161] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1162.hex dcs1162] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1163.hex dcs1163] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1164.hex dcs1164] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1165.hex dcs1165] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1166.hex dcs1166] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1167.hex dcs1167] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1168.hex dcs1168] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1169.hex dcs1169]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1170.hex dcs1170] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1171.hex dcs1171] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1172.hex dcs1172] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1173.hex dcs1173] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1174.hex dcs1174] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1175.hex dcs1175] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1176.hex dcs1176] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1177.hex dcs1177] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1178.hex dcs1178] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1179.hex dcs1179]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1180.hex dcs1180] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1181.hex dcs1181] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1182.hex dcs1182] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1183.hex dcs1183] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1184.hex dcs1184] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1185.hex dcs1185] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1186.hex dcs1186] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1187.hex dcs1187] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1188.hex dcs1188] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1189.hex dcs1189]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1190.hex dcs1190] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1191.hex dcs1191] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1192.hex dcs1192] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1193.hex dcs1193] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1194.hex dcs1194] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1195.hex dcs1195] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1196.hex dcs1196] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1197.hex dcs1197] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1198.hex dcs1198] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1199.hex dcs1199]<br> '''1200 - 1299'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1200.hex dcs1200] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1201.hex dcs1201] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1202.hex dcs1202] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1203.hex dcs1203] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1204.hex dcs1204] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1205.hex dcs1205] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1206.hex dcs1206] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1207.hex dcs1207] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1208.hex dcs1208] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1209.hex dcs1209]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1210.hex dcs1210] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1211.hex dcs1211] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1212.hex dcs1212] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1213.hex dcs1213] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1214.hex dcs1214] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1215.hex dcs1215] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1216.hex dcs1216] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1217.hex dcs1217] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1218.hex dcs1218] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1219.hex dcs1219]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1220.hex dcs1220] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1221.hex dcs1221] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1222.hex dcs1222] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1223.hex dcs1223] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1224.hex dcs1224] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1225.hex dcs1225] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1226.hex dcs1226] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1227.hex dcs1227] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1228.hex dcs1228] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1229.hex dcs1229]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1230.hex dcs1230] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1231.hex dcs1231] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1232.hex dcs1232] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1233.hex dcs1233] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1234.hex dcs1234] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1235.hex dcs1235] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1236.hex dcs1236] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1237.hex dcs1237] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1238.hex dcs1238] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1239.hex dcs1239]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1240.hex dcs1240] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1241.hex dcs1241] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1242.hex dcs1242] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1243.hex dcs1243] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1244.hex dcs1244] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1245.hex dcs1245] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1246.hex dcs1246] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1247.hex dcs1247] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1248.hex dcs1248] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1249.hex dcs1249]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1250.hex dcs1250] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1251.hex dcs1251] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1252.hex dcs1252] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1253.hex dcs1253] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1254.hex dcs1254] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1255.hex dcs1255] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1256.hex dcs1256] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1257.hex dcs1257] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1258.hex dcs1258] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1259.hex dcs1259]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1260.hex dcs1260] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1261.hex dcs1261] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1262.hex dcs1262] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1263.hex dcs1263] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1264.hex dcs1264] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1265.hex dcs1265] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1266.hex dcs1266] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1267.hex dcs1267] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1268.hex dcs1268] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1269.hex dcs1269]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1270.hex dcs1270] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1271.hex dcs1271] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1272.hex dcs1272] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1273.hex dcs1273] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1274.hex dcs1274] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1275.hex dcs1275] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1276.hex dcs1276] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1277.hex dcs1277] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1278.hex dcs1278] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1279.hex dcs1279]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1280.hex dcs1280] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1281.hex dcs1281] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1282.hex dcs1282] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1283.hex dcs1283] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1284.hex dcs1284] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1285.hex dcs1285] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1286.hex dcs1286] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1287.hex dcs1287] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1288.hex dcs1288] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1289.hex dcs1289]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1290.hex dcs1290] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1291.hex dcs1291] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1292.hex dcs1292] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1293.hex dcs1293] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1294.hex dcs1294] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1295.hex dcs1295] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1296.hex dcs1296] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1297.hex dcs1297] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1298.hex dcs1298] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1299.hex dcs1299]<br> '''1300 - 1399'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1300.hex dcs1300] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1301.hex dcs1301] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1302.hex dcs1302] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1303.hex dcs1303] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1304.hex dcs1304] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1305.hex dcs1305] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1306.hex dcs1306] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1307.hex dcs1307] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1308.hex dcs1308] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1309.hex dcs1309]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1310.hex dcs1310] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1311.hex dcs1311] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1312.hex dcs1312] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1313.hex dcs1313] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1314.hex dcs1314] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1315.hex dcs1315] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1316.hex dcs1316] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1317.hex dcs1317] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1318.hex dcs1318] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1319.hex dcs1319]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1320.hex dcs1320] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1321.hex dcs1321] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1322.hex dcs1322] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1323.hex dcs1323] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1324.hex dcs1324] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1325.hex dcs1325] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1326.hex dcs1326] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1327.hex dcs1327] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1328.hex dcs1328] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1329.hex dcs1329]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1330.hex dcs1330] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1331.hex dcs1331] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1332.hex dcs1332] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1333.hex dcs1333] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1334.hex dcs1334] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1335.hex dcs1335] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1336.hex dcs1336] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1337.hex dcs1337] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1338.hex dcs1338] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1339.hex dcs1339]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1340.hex dcs1340] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1341.hex dcs1341] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1342.hex dcs1342] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1343.hex dcs1343] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1344.hex dcs1344] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1345.hex dcs1345] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1346.hex dcs1346] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1347.hex dcs1347] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1348.hex dcs1348] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1349.hex dcs1349]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1350.hex dcs1350] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1351.hex dcs1351] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1352.hex dcs1352] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1353.hex dcs1353] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1354.hex dcs1354] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1355.hex dcs1355] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1356.hex dcs1356] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1357.hex dcs1357] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1358.hex dcs1358] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1359.hex dcs1359]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1360.hex dcs1360] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1361.hex dcs1361] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1362.hex dcs1362] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1363.hex dcs1363] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1364.hex dcs1364] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1365.hex dcs1365] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1366.hex dcs1366] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1367.hex dcs1367] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1368.hex dcs1368] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1369.hex dcs1369]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1370.hex dcs1370] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1371.hex dcs1371] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1372.hex dcs1372] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1373.hex dcs1373] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1374.hex dcs1374] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1375.hex dcs1375] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1376.hex dcs1376] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1377.hex dcs1377] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1378.hex dcs1378] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1379.hex dcs1379]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1380.hex dcs1380] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1381.hex dcs1381] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1382.hex dcs1382] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1383.hex dcs1383] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1384.hex dcs1384] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1385.hex dcs1385] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1386.hex dcs1386] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1387.hex dcs1387] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1388.hex dcs1388] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1389.hex dcs1389]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1390.hex dcs1390] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1391.hex dcs1391] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1392.hex dcs1392] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1393.hex dcs1393] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1394.hex dcs1394] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1395.hex dcs1395] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1396.hex dcs1396] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1397.hex dcs1397] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1398.hex dcs1398] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1399.hex dcs1399] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1400.hex dcs1400] 14e93b9bc362c4867035246fd33cebf10f4b7735 1724 1723 2012-01-30T11:53:42Z Dfe002 7 wikitext text/x-wiki '''30 - 100'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0030.hex dcs0030] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0031.hex dcs0031] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0032.hex dcs0032] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0033.hex dcs0033] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0034.hex dcs0034] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0035.hex dcs0035] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0036.hex dcs0036] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0037.hex dcs0037] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0038.hex dcs0038] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0039.hex dcs0039]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0040.hex dcs0040] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0041.hex dcs0041] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0042.hex dcs0042] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0043.hex dcs0043] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0044.hex dcs0044] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0045.hex dcs0045] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0046.hex dcs0046] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0047.hex dcs0047] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0048.hex dcs0048] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0049.hex dcs0049]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0050.hex dcs0050] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0051.hex dcs0051] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0052.hex dcs0052] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0053.hex dcs0053] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0054.hex dcs0054] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0055.hex dcs0055] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0056.hex dcs0056] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0057.hex dcs0057] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0058.hex dcs0058] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0059.hex dcs0059]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0060.hex dcs0060] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0061.hex dcs0061] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0062.hex dcs0062] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0063.hex dcs0063] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0064.hex dcs0064] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0065.hex dcs0065] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0066.hex dcs0066] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0067.hex dcs0067] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0068.hex dcs0068] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0069.hex dcs0069]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0070.hex dcs0070] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0071.hex dcs0071] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0072.hex dcs0072] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0073.hex dcs0073] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0074.hex dcs0074] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0075.hex dcs0075] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0076.hex dcs0076] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0077.hex dcs0077] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0078.hex dcs0078] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0079.hex dcs0079]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0080.hex dcs0080] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0081.hex dcs0081] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0082.hex dcs0082] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0083.hex dcs0083] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0084.hex dcs0084] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0085.hex dcs0085] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0086.hex dcs0086] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0087.hex dcs0087] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0088.hex dcs0088] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0089.hex dcs0089]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0090.hex dcs0090] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0091.hex dcs0091] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0092.hex dcs0092] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0093.hex dcs0093] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0094.hex dcs0094] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0095.hex dcs0095] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0096.hex dcs0096] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0097.hex dcs0097] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0098.hex dcs0098] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0099.hex dcs0099]<br> '''100 - 199'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0100.hex dcs0100] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0101.hex dcs0101] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0102.hex dcs0102] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0103.hex dcs0103] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0104.hex dcs0104] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0105.hex dcs0105] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0106.hex dcs0106] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0107.hex dcs0107] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0108.hex dcs0108] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0109.hex dcs0109]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0110.hex dcs0110] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0111.hex dcs0111] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0112.hex dcs0112] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0113.hex dcs0113] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0114.hex dcs0114] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0115.hex dcs0115] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0116.hex dcs0116] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0117.hex dcs0117] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0118.hex dcs0118] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0119.hex dcs0119]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0120.hex dcs0120] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0121.hex dcs0121] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0122.hex dcs0122] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0123.hex dcs0123] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0124.hex dcs0124] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0125.hex dcs0125] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0126.hex dcs0126] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0127.hex dcs0127] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0128.hex dcs0128] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0129.hex dcs0129]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0130.hex dcs0130] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0131.hex dcs0131] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0132.hex dcs0132] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0133.hex dcs0133] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0134.hex dcs0134] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0135.hex dcs0135] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0136.hex dcs0136] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0137.hex dcs0137] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0138.hex dcs0138] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0139.hex dcs0139]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0140.hex dcs0140] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0141.hex dcs0141] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0142.hex dcs0142] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0143.hex dcs0143] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0144.hex dcs0144] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0145.hex dcs0145] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0146.hex dcs0146] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0147.hex dcs0147] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0148.hex dcs0148] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0149.hex dcs0149]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0150.hex dcs0150] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0151.hex dcs0151] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0152.hex dcs0152] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0153.hex dcs0153] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0154.hex dcs0154] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0155.hex dcs0155] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0156.hex dcs0156] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0157.hex dcs0157] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0158.hex dcs0158] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0159.hex dcs0159]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0160.hex dcs0160] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0161.hex dcs0161] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0162.hex dcs0162] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0163.hex dcs0163] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0164.hex dcs0164] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0165.hex dcs0165] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0166.hex dcs0166] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0167.hex dcs0167] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0168.hex dcs0168] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0169.hex dcs0169]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0170.hex dcs0170] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0171.hex dcs0171] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0172.hex dcs0172] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0173.hex dcs0173] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0174.hex dcs0174] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0175.hex dcs0175] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0176.hex dcs0176] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0177.hex dcs0177] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0178.hex dcs0178] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0179.hex dcs0179]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0180.hex dcs0180] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0181.hex dcs0181] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0182.hex dcs0182] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0183.hex dcs0183] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0184.hex dcs0184] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0185.hex dcs0185] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0186.hex dcs0186] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0187.hex dcs0187] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0188.hex dcs0188] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0189.hex dcs0189]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0190.hex dcs0190] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0191.hex dcs0191] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0192.hex dcs0192] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0193.hex dcs0193] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0194.hex dcs0194] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0195.hex dcs0195] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0196.hex dcs0196] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0197.hex dcs0197] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0198.hex dcs0198] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0199.hex dcs0199]<br> '''200 - 299'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0200.hex dcs0200] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0201.hex dcs0201] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0202.hex dcs0202] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0203.hex dcs0203] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0204.hex dcs0204] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0205.hex dcs0205] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0206.hex dcs0206] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0207.hex dcs0207] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0208.hex dcs0208] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0209.hex dcs0209]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0210.hex dcs0210] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0211.hex dcs0211] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0212.hex dcs0212] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0213.hex dcs0213] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0214.hex dcs0214] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0215.hex dcs0215] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0216.hex dcs0216] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0217.hex dcs0217] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0218.hex dcs0218] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0219.hex dcs0219]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0220.hex dcs0220] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0221.hex dcs0221] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0222.hex dcs0222] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0223.hex dcs0223] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0224.hex dcs0224] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0225.hex dcs0225] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0226.hex dcs0226] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0227.hex dcs0227] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0228.hex dcs0228] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0229.hex dcs0229]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0230.hex dcs0230] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0231.hex dcs0231] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0232.hex dcs0232] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0233.hex dcs0233] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0234.hex dcs0234] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0235.hex dcs0235] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0236.hex dcs0236] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0237.hex dcs0237] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0238.hex dcs0238] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0239.hex dcs0239]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0240.hex dcs0240] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0241.hex dcs0241] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0242.hex dcs0242] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0243.hex dcs0243] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0244.hex dcs0244] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0245.hex dcs0245] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0246.hex dcs0246] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0247.hex dcs0247] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0248.hex dcs0248] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0249.hex dcs0249]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0250.hex dcs0250] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0251.hex dcs0251] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0252.hex dcs0252] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0253.hex dcs0253] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0254.hex dcs0254] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0255.hex dcs0255] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0256.hex dcs0256] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0257.hex dcs0257] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0258.hex dcs0258] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0259.hex dcs0259]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0260.hex dcs0260] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0261.hex dcs0261] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0262.hex dcs0262] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0263.hex dcs0263] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0264.hex dcs0264] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0265.hex dcs0265] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0266.hex dcs0266] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0267.hex dcs0267] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0268.hex dcs0268] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0269.hex dcs0269]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0270.hex dcs0270] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0271.hex dcs0271] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0272.hex dcs0272] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0273.hex dcs0273] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0274.hex dcs0274] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0275.hex dcs0275] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0276.hex dcs0276] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0277.hex dcs0277] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0278.hex dcs0278] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0279.hex dcs0279]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0280.hex dcs0280] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0281.hex dcs0281] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0282.hex dcs0282] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0283.hex dcs0283] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0284.hex dcs0284] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0285.hex dcs0285] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0286.hex dcs0286] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0287.hex dcs0287] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0288.hex dcs0288] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0289.hex dcs0289]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0290.hex dcs0290] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0291.hex dcs0291] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0292.hex dcs0292] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0293.hex dcs0293] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0294.hex dcs0294] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0295.hex dcs0295] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0296.hex dcs0296] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0297.hex dcs0297] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0298.hex dcs0298] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0299.hex dcs0299]<br> '''300 - 399'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0300.hex dcs0300] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0301.hex dcs0301] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0302.hex dcs0302] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0303.hex dcs0303] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0304.hex dcs0304] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0305.hex dcs0305] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0306.hex dcs0306] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0307.hex dcs0307] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0308.hex dcs0308] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0309.hex dcs0309]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0310.hex dcs0310] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0311.hex dcs0311] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0312.hex dcs0312] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0313.hex dcs0313] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0314.hex dcs0314] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0315.hex dcs0315] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0316.hex dcs0316] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0317.hex dcs0317] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0318.hex dcs0318] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0319.hex dcs0319]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0320.hex dcs0320] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0321.hex dcs0321] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0322.hex dcs0322] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0323.hex dcs0323] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0324.hex dcs0324] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0325.hex dcs0325] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0326.hex dcs0326] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0327.hex dcs0327] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0328.hex dcs0328] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0329.hex dcs0329]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0330.hex dcs0330] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0331.hex dcs0331] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0332.hex dcs0332] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0333.hex dcs0333] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0334.hex dcs0334] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0335.hex dcs0335] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0336.hex dcs0336] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0337.hex dcs0337] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0338.hex dcs0338] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0339.hex dcs0339]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0340.hex dcs0340] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0341.hex dcs0341] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0342.hex dcs0342] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0343.hex dcs0343] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0344.hex dcs0344] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0345.hex dcs0345] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0346.hex dcs0346] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0347.hex dcs0347] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0348.hex dcs0348] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0349.hex dcs0349]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0350.hex dcs0350] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0351.hex dcs0351] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0352.hex dcs0352] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0353.hex dcs0353] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0354.hex dcs0354] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0355.hex dcs0355] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0356.hex dcs0356] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0357.hex dcs0357] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0358.hex dcs0358] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0359.hex dcs0359]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0360.hex dcs0360] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0361.hex dcs0361] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0362.hex dcs0362] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0363.hex dcs0363] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0364.hex dcs0364] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0365.hex dcs0365] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0366.hex dcs0366] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0367.hex dcs0367] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0368.hex dcs0368] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0369.hex dcs0369]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0370.hex dcs0370] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0371.hex dcs0371] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0372.hex dcs0372] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0373.hex dcs0373] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0374.hex dcs0374] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0375.hex dcs0375] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0376.hex dcs0376] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0377.hex dcs0377] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0378.hex dcs0378] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0379.hex dcs0379]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0380.hex dcs0380] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0381.hex dcs0381] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0382.hex dcs0382] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0383.hex dcs0383] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0384.hex dcs0384] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0385.hex dcs0385] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0386.hex dcs0386] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0387.hex dcs0387] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0388.hex dcs0388] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0389.hex dcs0389]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0390.hex dcs0390] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0391.hex dcs0391] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0392.hex dcs0392] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0393.hex dcs0393] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0394.hex dcs0394] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0395.hex dcs0395] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0396.hex dcs0396] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0397.hex dcs0397] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0398.hex dcs0398] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0399.hex dcs0399]<br> '''400 - 499'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0400.hex dcs0400] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0401.hex dcs0401] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0402.hex dcs0402] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0403.hex dcs0403] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0404.hex dcs0404] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0405.hex dcs0405] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0406.hex dcs0406] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0407.hex dcs0407] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0408.hex dcs0408] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0409.hex dcs0409]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0410.hex dcs0410] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0411.hex dcs0411] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0412.hex dcs0412] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0413.hex dcs0413] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0414.hex dcs0414] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0415.hex dcs0415] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0416.hex dcs0416] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0417.hex dcs0417] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0418.hex dcs0418] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0419.hex dcs0419]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0420.hex dcs0420] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0421.hex dcs0421] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0422.hex dcs0422] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0423.hex dcs0423] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0424.hex dcs0424] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0425.hex dcs0425] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0426.hex dcs0426] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0427.hex dcs0427] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0428.hex dcs0428] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0429.hex dcs0429]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0430.hex dcs0430] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0431.hex dcs0431] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0432.hex dcs0432] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0433.hex dcs0433] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0434.hex dcs0434] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0435.hex dcs0435] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0436.hex dcs0436] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0437.hex dcs0437] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0438.hex dcs0438] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0439.hex dcs0439]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0440.hex dcs0440] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0441.hex dcs0441] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0442.hex dcs0442] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0443.hex dcs0443] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0444.hex dcs0444] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0445.hex dcs0445] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0446.hex dcs0446] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0447.hex dcs0447] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0448.hex dcs0448] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0449.hex dcs0449]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0450.hex dcs0450] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0451.hex dcs0451] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0452.hex dcs0452] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0453.hex dcs0453] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0454.hex dcs0454] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0455.hex dcs0455] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0456.hex dcs0456] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0457.hex dcs0457] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0458.hex dcs0458] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0459.hex dcs0459]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0460.hex dcs0460] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0461.hex dcs0461] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0462.hex dcs0462] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0463.hex dcs0463] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0464.hex dcs0464] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0465.hex dcs0465] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0466.hex dcs0466] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0467.hex dcs0467] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0468.hex dcs0468] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0469.hex dcs0469]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0470.hex dcs0470] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0471.hex dcs0471] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0472.hex dcs0472] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0473.hex dcs0473] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0474.hex dcs0474] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0475.hex dcs0475] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0476.hex dcs0476] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0477.hex dcs0477] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0478.hex dcs0478] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0479.hex dcs0479]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0480.hex dcs0480] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0481.hex dcs0481] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0482.hex dcs0482] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0483.hex dcs0483] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0484.hex dcs0484] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0485.hex dcs0485] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0486.hex dcs0486] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0487.hex dcs0487] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0488.hex dcs0488] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0489.hex dcs0489]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0490.hex dcs0490] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0491.hex dcs0491] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0492.hex dcs0492] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0493.hex dcs0493] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0494.hex dcs0494] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0495.hex dcs0495] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0496.hex dcs0496] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0497.hex dcs0497] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0498.hex dcs0498] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0499.hex dcs0499]<br> '''500 - 599'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0500.hex dcs0500] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0501.hex dcs0501] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0502.hex dcs0502] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0503.hex dcs0503] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0504.hex dcs0504] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0505.hex dcs0505] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0506.hex dcs0506] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0507.hex dcs0507] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0508.hex dcs0508] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0509.hex dcs0509]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0510.hex dcs0510] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0511.hex dcs0511] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0512.hex dcs0512] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0513.hex dcs0513] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0514.hex dcs0514] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0515.hex dcs0515] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0516.hex dcs0516] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0517.hex dcs0517] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0518.hex dcs0518] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0519.hex dcs0519]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0520.hex dcs0520] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0521.hex dcs0521] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0522.hex dcs0522] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0523.hex dcs0523] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0524.hex dcs0524] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0525.hex dcs0525] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0526.hex dcs0526] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0527.hex dcs0527] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0528.hex dcs0528] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0529.hex dcs0529]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0530.hex dcs0530] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0531.hex dcs0531] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0532.hex dcs0532] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0533.hex dcs0533] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0534.hex dcs0534] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0535.hex dcs0535] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0536.hex dcs0536] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0537.hex dcs0537] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0538.hex dcs0538] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0539.hex dcs0539]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0540.hex dcs0540] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0541.hex dcs0541] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0542.hex dcs0542] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0543.hex dcs0543] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0544.hex dcs0544] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0545.hex dcs0545] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0546.hex dcs0546] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0547.hex dcs0547] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0548.hex dcs0548] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0549.hex dcs0549]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0550.hex dcs0550] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0551.hex dcs0551] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0552.hex dcs0552] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0553.hex dcs0553] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0554.hex dcs0554] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0555.hex dcs0555] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0556.hex dcs0556] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0557.hex dcs0557] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0558.hex dcs0558] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0559.hex dcs0559]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0560.hex dcs0560] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0561.hex dcs0561] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0562.hex dcs0562] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0563.hex dcs0563] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0564.hex dcs0564] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0565.hex dcs0565] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0566.hex dcs0566] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0567.hex dcs0567] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0568.hex dcs0568] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0569.hex dcs0569]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0570.hex dcs0570] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0571.hex dcs0571] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0572.hex dcs0572] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0573.hex dcs0573] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0574.hex dcs0574] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0575.hex dcs0575] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0576.hex dcs0576] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0577.hex dcs0577] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0578.hex dcs0578] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0579.hex dcs0579]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0580.hex dcs0580] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0581.hex dcs0581] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0582.hex dcs0582] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0583.hex dcs0583] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0584.hex dcs0584] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0585.hex dcs0585] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0586.hex dcs0586] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0587.hex dcs0587] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0588.hex dcs0588] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0589.hex dcs0589]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0590.hex dcs0590] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0591.hex dcs0591] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0592.hex dcs0592] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0593.hex dcs0593] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0594.hex dcs0594] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0595.hex dcs0595] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0596.hex dcs0596] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0597.hex dcs0597] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0598.hex dcs0598] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0599.hex dcs0599]<br> '''600 - 699'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0600.hex dcs0600] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0601.hex dcs0601] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0602.hex dcs0602] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0603.hex dcs0603] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0604.hex dcs0604] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0605.hex dcs0605] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0606.hex dcs0606] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0607.hex dcs0607] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0608.hex dcs0608] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0609.hex dcs0609]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0610.hex dcs0610] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0611.hex dcs0611] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0612.hex dcs0612] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0613.hex dcs0613] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0614.hex dcs0614] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0615.hex dcs0615] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0616.hex dcs0616] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0617.hex dcs0617] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0618.hex dcs0618] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0619.hex dcs0619]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0620.hex dcs0620] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0621.hex dcs0621] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0622.hex dcs0622] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0623.hex dcs0623] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0624.hex dcs0624] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0625.hex dcs0625] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0626.hex dcs0626] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0627.hex dcs0627] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0628.hex dcs0628] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0629.hex dcs0629]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0630.hex dcs0630] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0631.hex dcs0631] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0632.hex dcs0632] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0633.hex dcs0633] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0634.hex dcs0634] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0635.hex dcs0635] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0636.hex dcs0636] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0637.hex dcs0637] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0638.hex dcs0638] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0639.hex dcs0639]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0640.hex dcs0640] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0641.hex dcs0641] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0642.hex dcs0642] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0643.hex dcs0643] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0644.hex dcs0644] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0645.hex dcs0645] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0646.hex dcs0646] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0647.hex dcs0647] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0648.hex dcs0648] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0649.hex dcs0649]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0650.hex dcs0650] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0651.hex dcs0651] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0652.hex dcs0652] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0653.hex dcs0653] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0654.hex dcs0654] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0655.hex dcs0655] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0656.hex dcs0656] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0657.hex dcs0657] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0658.hex dcs0658] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0659.hex dcs0659]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0660.hex dcs0660] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0661.hex dcs0661] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0662.hex dcs0662] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0663.hex dcs0663] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0664.hex dcs0664] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0665.hex dcs0665] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0666.hex dcs0666] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0667.hex dcs0667] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0668.hex dcs0668] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0669.hex dcs0669]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0670.hex dcs0670] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0671.hex dcs0671] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0672.hex dcs0672] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0673.hex dcs0673] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0674.hex dcs0674] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0675.hex dcs0675] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0676.hex dcs0676] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0677.hex dcs0677] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0678.hex dcs0678] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0679.hex dcs0679]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0680.hex dcs0680] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0681.hex dcs0681] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0682.hex dcs0682] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0683.hex dcs0683] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0684.hex dcs0684] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0685.hex dcs0685] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0686.hex dcs0686] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0687.hex dcs0687] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0688.hex dcs0688] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0689.hex dcs0689]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0690.hex dcs0690] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0691.hex dcs0691] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0692.hex dcs0692] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0693.hex dcs0693] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0694.hex dcs0694] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0695.hex dcs0695] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0696.hex dcs0696] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0697.hex dcs0697] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0698.hex dcs0698] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0699.hex dcs0699]<br> '''700 - 799'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0700.hex dcs0700] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0701.hex dcs0701] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0702.hex dcs0702] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0703.hex dcs0703] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0704.hex dcs0704] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0705.hex dcs0705] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0706.hex dcs0706] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0707.hex dcs0707] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0708.hex dcs0708] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0709.hex dcs0709]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0710.hex dcs0710] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0711.hex dcs0711] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0712.hex dcs0712] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0713.hex dcs0713] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0714.hex dcs0714] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0715.hex dcs0715] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0716.hex dcs0716] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0717.hex dcs0717] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0718.hex dcs0718] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0719.hex dcs0719]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0720.hex dcs0720] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0721.hex dcs0721] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0722.hex dcs0722] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0723.hex dcs0723] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0724.hex dcs0724] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0725.hex dcs0725] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0726.hex dcs0726] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0727.hex dcs0727] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0728.hex dcs0728] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0729.hex dcs0729]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0730.hex dcs0730] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0731.hex dcs0731] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0732.hex dcs0732] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0733.hex dcs0733] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0734.hex dcs0734] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0735.hex dcs0735] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0736.hex dcs0736] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0737.hex dcs0737] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0738.hex dcs0738] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0739.hex dcs0739]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0740.hex dcs0740] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0741.hex dcs0741] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0742.hex dcs0742] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0743.hex dcs0743] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0744.hex dcs0744] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0745.hex dcs0745] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0746.hex dcs0746] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0747.hex dcs0747] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0748.hex dcs0748] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0749.hex dcs0749]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0750.hex dcs0750] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0751.hex dcs0751] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0752.hex dcs0752] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0753.hex dcs0753] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0754.hex dcs0754] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0755.hex dcs0755] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0756.hex dcs0756] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0757.hex dcs0757] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0758.hex dcs0758] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0759.hex dcs0759]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0760.hex dcs0760] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0761.hex dcs0761] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0762.hex dcs0762] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0763.hex dcs0763] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0764.hex dcs0764] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0765.hex dcs0765] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0766.hex dcs0766] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0767.hex dcs0767] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0768.hex dcs0768] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0769.hex dcs0769]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0770.hex dcs0770] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0771.hex dcs0771] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0772.hex dcs0772] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0773.hex dcs0773] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0774.hex dcs0774] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0775.hex dcs0775] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0776.hex dcs0776] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0777.hex dcs0777] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0778.hex dcs0778] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0779.hex dcs0779]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0780.hex dcs0780] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0781.hex dcs0781] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0782.hex dcs0782] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0783.hex dcs0783] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0784.hex dcs0784] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0785.hex dcs0785] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0786.hex dcs0786] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0787.hex dcs0787] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0788.hex dcs0788] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0789.hex dcs0789]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0790.hex dcs0790] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0791.hex dcs0791] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0792.hex dcs0792] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0793.hex dcs0793] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0794.hex dcs0794] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0795.hex dcs0795] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0796.hex dcs0796] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0797.hex dcs0797] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0798.hex dcs0798] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0799.hex dcs0799]<br> '''800 - 899'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0800.hex dcs0800] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0801.hex dcs0801] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0802.hex dcs0802] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0803.hex dcs0803] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0804.hex dcs0804] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0805.hex dcs0805] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0806.hex dcs0806] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0807.hex dcs0807] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0808.hex dcs0808] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0809.hex dcs0809]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0810.hex dcs0810] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0811.hex dcs0811] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0812.hex dcs0812] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0813.hex dcs0813] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0814.hex dcs0814] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0815.hex dcs0815] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0816.hex dcs0816] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0817.hex dcs0817] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0818.hex dcs0818] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0819.hex dcs0819]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0820.hex dcs0820] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0821.hex dcs0821] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0822.hex dcs0822] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0823.hex dcs0823] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0824.hex dcs0824] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0825.hex dcs0825] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0826.hex dcs0826] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0827.hex dcs0827] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0828.hex dcs0828] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0829.hex dcs0829]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0830.hex dcs0830] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0831.hex dcs0831] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0832.hex dcs0832] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0833.hex dcs0833] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0834.hex dcs0834] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0835.hex dcs0835] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0836.hex dcs0836] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0837.hex dcs0837] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0838.hex dcs0838] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0839.hex dcs0839]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0840.hex dcs0840] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0841.hex dcs0841] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0842.hex dcs0842] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0843.hex dcs0843] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0844.hex dcs0844] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0845.hex dcs0845] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0846.hex dcs0846] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0847.hex dcs0847] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0848.hex dcs0848] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0849.hex dcs0849]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0850.hex dcs0850] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0851.hex dcs0851] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0852.hex dcs0852] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0853.hex dcs0853] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0854.hex dcs0854] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0855.hex dcs0855] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0856.hex dcs0856] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0857.hex dcs0857] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0858.hex dcs0858] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0859.hex dcs0859]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0860.hex dcs0860] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0861.hex dcs0861] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0862.hex dcs0862] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0863.hex dcs0863] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0864.hex dcs0864] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0865.hex dcs0865] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0866.hex dcs0866] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0867.hex dcs0867] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0868.hex dcs0868] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0869.hex dcs0869]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0870.hex dcs0870] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0871.hex dcs0871] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0872.hex dcs0872] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0873.hex dcs0873] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0874.hex dcs0874] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0875.hex dcs0875] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0876.hex dcs0876] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0877.hex dcs0877] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0878.hex dcs0878] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0879.hex dcs0879]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0880.hex dcs0880] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0881.hex dcs0881] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0882.hex dcs0882] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0883.hex dcs0883] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0884.hex dcs0884] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0885.hex dcs0885] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0886.hex dcs0886] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0887.hex dcs0887] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0888.hex dcs0888] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0889.hex dcs0889]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0890.hex dcs0890] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0891.hex dcs0891] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0892.hex dcs0892] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0893.hex dcs0893] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0894.hex dcs0894] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0895.hex dcs0895] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0896.hex dcs0896] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0897.hex dcs0897] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0898.hex dcs0898] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0899.hex dcs0899]<br> '''900 - 999'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0900.hex dcs0900] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0901.hex dcs0901] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0902.hex dcs0902] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0903.hex dcs0903] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0904.hex dcs0904] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0905.hex dcs0905] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0906.hex dcs0906] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0907.hex dcs0907] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0908.hex dcs0908] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0909.hex dcs0909]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0910.hex dcs0910] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0911.hex dcs0911] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0912.hex dcs0912] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0913.hex dcs0913] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0914.hex dcs0914] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0915.hex dcs0915] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0916.hex dcs0916] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0917.hex dcs0917] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0918.hex dcs0918] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0919.hex dcs0919]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0920.hex dcs0920] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0921.hex dcs0921] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0922.hex dcs0922] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0923.hex dcs0923] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0924.hex dcs0924] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0925.hex dcs0925] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0926.hex dcs0926] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0927.hex dcs0927] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0928.hex dcs0928] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0929.hex dcs0929]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0930.hex dcs0930] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0931.hex dcs0931] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0932.hex dcs0932] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0933.hex dcs0933] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0934.hex dcs0934] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0935.hex dcs0935] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0936.hex dcs0936] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0937.hex dcs0937] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0938.hex dcs0938] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0939.hex dcs0939]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0940.hex dcs0940] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0941.hex dcs0941] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0942.hex dcs0942] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0943.hex dcs0943] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0944.hex dcs0944] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0945.hex dcs0945] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0946.hex dcs0946] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0947.hex dcs0947] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0948.hex dcs0948] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0949.hex dcs0949]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0950.hex dcs0950] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0951.hex dcs0951] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0952.hex dcs0952] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0953.hex dcs0953] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0954.hex dcs0954] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0955.hex dcs0955] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0956.hex dcs0956] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0957.hex dcs0957] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0958.hex dcs0958] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0959.hex dcs0959]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0960.hex dcs0960] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0961.hex dcs0961] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0962.hex dcs0962] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0963.hex dcs0963] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0964.hex dcs0964] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0965.hex dcs0965] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0966.hex dcs0966] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0967.hex dcs0967] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0968.hex dcs0968] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0969.hex dcs0969]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0970.hex dcs0970] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0971.hex dcs0971] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0972.hex dcs0972] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0973.hex dcs0973] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0974.hex dcs0974] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0975.hex dcs0975] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0976.hex dcs0976] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0977.hex dcs0977] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0978.hex dcs0978] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0979.hex dcs0979]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0980.hex dcs0980] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0981.hex dcs0981] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0982.hex dcs0982] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0983.hex dcs0983] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0984.hex dcs0984] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0985.hex dcs0985] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0986.hex dcs0986] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0987.hex dcs0987] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0988.hex dcs0988] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0989.hex dcs0989]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0990.hex dcs0990] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0991.hex dcs0991] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0992.hex dcs0992] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0993.hex dcs0993] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0994.hex dcs0994] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0995.hex dcs0995] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0996.hex dcs0996] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0997.hex dcs0997] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0998.hex dcs0998] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0999.hex dcs0999]<br> '''1000 - 1099'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1000.hex dcs1000] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1001.hex dcs1001] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1002.hex dcs1002] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1003.hex dcs1003] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1004.hex dcs1004] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1005.hex dcs1005] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1006.hex dcs1006] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1007.hex dcs1007] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1008.hex dcs1008] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1009.hex dcs1009]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1010.hex dcs1010] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1011.hex dcs1011] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1012.hex dcs1012] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1013.hex dcs1013] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1014.hex dcs1014] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1015.hex dcs1015] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1016.hex dcs1016] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1017.hex dcs1017] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1018.hex dcs1018] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1019.hex dcs1019]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1020.hex dcs1020] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1021.hex dcs1021] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1022.hex dcs1022] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1023.hex dcs1023] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1024.hex dcs1024] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1025.hex dcs1025] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1026.hex dcs1026] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1027.hex dcs1027] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1028.hex dcs1028] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1029.hex dcs1029]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1030.hex dcs1030] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1031.hex dcs1031] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1032.hex dcs1032] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1033.hex dcs1033] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1034.hex dcs1034] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1035.hex dcs1035] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1036.hex dcs1036] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1037.hex dcs1037] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1038.hex dcs1038] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1039.hex dcs1039]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1040.hex dcs1040] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1041.hex dcs1041] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1042.hex dcs1042] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1043.hex dcs1043] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1044.hex dcs1044] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1045.hex dcs1045] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1046.hex dcs1046] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1047.hex dcs1047] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1048.hex dcs1048] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1049.hex dcs1049]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1050.hex dcs1050] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1051.hex dcs1051] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1052.hex dcs1052] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1053.hex dcs1053] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1054.hex dcs1054] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1055.hex dcs1055] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1056.hex dcs1056] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1057.hex dcs1057] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1058.hex dcs1058] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1059.hex dcs1059]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1060.hex dcs1060] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1061.hex dcs1061] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1062.hex dcs1062] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1063.hex dcs1063] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1064.hex dcs1064] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1065.hex dcs1065] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1066.hex dcs1066] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1067.hex dcs1067] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1068.hex dcs1068] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1069.hex dcs1069]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1070.hex dcs1070] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1071.hex dcs1071] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1072.hex dcs1072] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1073.hex dcs1073] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1074.hex dcs1074] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1075.hex dcs1075] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1076.hex dcs1076] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1077.hex dcs1077] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1078.hex dcs1078] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1079.hex dcs1079]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1080.hex dcs1080] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1081.hex dcs1081] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1082.hex dcs1082] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1083.hex dcs1083] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1084.hex dcs1084] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1085.hex dcs1085] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1086.hex dcs1086] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1087.hex dcs1087] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1088.hex dcs1088] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1089.hex dcs1089]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1090.hex dcs1090] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1091.hex dcs1091] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1092.hex dcs1092] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1093.hex dcs1093] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1094.hex dcs1094] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1095.hex dcs1095] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1096.hex dcs1096] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1097.hex dcs1097] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1098.hex dcs1098] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1099.hex dcs1099]<br> '''1100 - 1199'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1100.hex dcs1100] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1101.hex dcs1101] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1102.hex dcs1102] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1103.hex dcs1103] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1104.hex dcs1104] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1105.hex dcs1105] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1106.hex dcs1106] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1107.hex dcs1107] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1108.hex dcs1108] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1109.hex dcs1109]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1110.hex dcs1110] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1111.hex dcs1111] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1112.hex dcs1112] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1113.hex dcs1113] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1114.hex dcs1114] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1115.hex dcs1115] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1116.hex dcs1116] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1117.hex dcs1117] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1118.hex dcs1118] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1119.hex dcs1119]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1120.hex dcs1120] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1121.hex dcs1121] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1122.hex dcs1122] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1123.hex dcs1123] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1124.hex dcs1124] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1125.hex dcs1125] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1126.hex dcs1126] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1127.hex dcs1127] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1128.hex dcs1128] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1129.hex dcs1129]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1130.hex dcs1130] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1131.hex dcs1131] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1132.hex dcs1132] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1133.hex dcs1133] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1134.hex dcs1134] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1135.hex dcs1135] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1136.hex dcs1136] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1137.hex dcs1137] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1138.hex dcs1138] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1139.hex dcs1139]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1140.hex dcs1140] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1141.hex dcs1141] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1142.hex dcs1142] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1143.hex dcs1143] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1144.hex dcs1144] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1145.hex dcs1145] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1146.hex dcs1146] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1147.hex dcs1147] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1148.hex dcs1148] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1149.hex dcs1149]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1150.hex dcs1150] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1151.hex dcs1151] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1152.hex dcs1152] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1153.hex dcs1153] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1154.hex dcs1154] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1155.hex dcs1155] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1156.hex dcs1156] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1157.hex dcs1157] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1158.hex dcs1158] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1159.hex dcs1159]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1160.hex dcs1160] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1161.hex dcs1161] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1162.hex dcs1162] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1163.hex dcs1163] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1164.hex dcs1164] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1165.hex dcs1165] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1166.hex dcs1166] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1167.hex dcs1167] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1168.hex dcs1168] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1169.hex dcs1169]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1170.hex dcs1170] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1171.hex dcs1171] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1172.hex dcs1172] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1173.hex dcs1173] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1174.hex dcs1174] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1175.hex dcs1175] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1176.hex dcs1176] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1177.hex dcs1177] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1178.hex dcs1178] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1179.hex dcs1179]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1180.hex dcs1180] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1181.hex dcs1181] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1182.hex dcs1182] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1183.hex dcs1183] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1184.hex dcs1184] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1185.hex dcs1185] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1186.hex dcs1186] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1187.hex dcs1187] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1188.hex dcs1188] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1189.hex dcs1189]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1190.hex dcs1190] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1191.hex dcs1191] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1192.hex dcs1192] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1193.hex dcs1193] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1194.hex dcs1194] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1195.hex dcs1195] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1196.hex dcs1196] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1197.hex dcs1197] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1198.hex dcs1198] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1199.hex dcs1199]<br> '''1200 - 1299'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1200.hex dcs1200] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1201.hex dcs1201] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1202.hex dcs1202] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1203.hex dcs1203] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1204.hex dcs1204] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1205.hex dcs1205] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1206.hex dcs1206] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1207.hex dcs1207] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1208.hex dcs1208] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1209.hex dcs1209]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1210.hex dcs1210] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1211.hex dcs1211] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1212.hex dcs1212] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1213.hex dcs1213] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1214.hex dcs1214] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1215.hex dcs1215] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1216.hex dcs1216] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1217.hex dcs1217] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1218.hex dcs1218] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1219.hex dcs1219]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1220.hex dcs1220] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1221.hex dcs1221] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1222.hex dcs1222] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1223.hex dcs1223] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1224.hex dcs1224] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1225.hex dcs1225] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1226.hex dcs1226] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1227.hex dcs1227] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1228.hex dcs1228] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1229.hex dcs1229]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1230.hex dcs1230] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1231.hex dcs1231] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1232.hex dcs1232] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1233.hex dcs1233] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1234.hex dcs1234] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1235.hex dcs1235] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1236.hex dcs1236] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1237.hex dcs1237] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1238.hex dcs1238] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1239.hex dcs1239]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1240.hex dcs1240] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1241.hex dcs1241] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1242.hex dcs1242] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1243.hex dcs1243] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1244.hex dcs1244] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1245.hex dcs1245] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1246.hex dcs1246] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1247.hex dcs1247] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1248.hex dcs1248] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1249.hex dcs1249]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1250.hex dcs1250] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1251.hex dcs1251] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1252.hex dcs1252] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1253.hex dcs1253] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1254.hex dcs1254] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1255.hex dcs1255] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1256.hex dcs1256] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1257.hex dcs1257] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1258.hex dcs1258] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1259.hex dcs1259]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1260.hex dcs1260] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1261.hex dcs1261] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1262.hex dcs1262] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1263.hex dcs1263] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1264.hex dcs1264] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1265.hex dcs1265] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1266.hex dcs1266] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1267.hex dcs1267] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1268.hex dcs1268] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1269.hex dcs1269]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1270.hex dcs1270] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1271.hex dcs1271] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1272.hex dcs1272] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1273.hex dcs1273] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1274.hex dcs1274] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1275.hex dcs1275] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1276.hex dcs1276] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1277.hex dcs1277] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1278.hex dcs1278] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1279.hex dcs1279]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1280.hex dcs1280] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1281.hex dcs1281] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1282.hex dcs1282] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1283.hex dcs1283] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1284.hex dcs1284] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1285.hex dcs1285] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1286.hex dcs1286] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1287.hex dcs1287] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1288.hex dcs1288] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1289.hex dcs1289]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1290.hex dcs1290] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1291.hex dcs1291] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1292.hex dcs1292] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1293.hex dcs1293] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1294.hex dcs1294] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1295.hex dcs1295] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1296.hex dcs1296] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1297.hex dcs1297] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1298.hex dcs1298] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1299.hex dcs1299]<br> '''1300 - 1400'''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1300.hex dcs1300] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1301.hex dcs1301] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1302.hex dcs1302] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1303.hex dcs1303] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1304.hex dcs1304] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1305.hex dcs1305] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1306.hex dcs1306] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1307.hex dcs1307] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1308.hex dcs1308] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1309.hex dcs1309]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1310.hex dcs1310] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1311.hex dcs1311] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1312.hex dcs1312] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1313.hex dcs1313] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1314.hex dcs1314] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1315.hex dcs1315] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1316.hex dcs1316] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1317.hex dcs1317] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1318.hex dcs1318] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1319.hex dcs1319]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1320.hex dcs1320] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1321.hex dcs1321] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1322.hex dcs1322] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1323.hex dcs1323] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1324.hex dcs1324] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1325.hex dcs1325] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1326.hex dcs1326] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1327.hex dcs1327] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1328.hex dcs1328] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1329.hex dcs1329]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1330.hex dcs1330] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1331.hex dcs1331] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1332.hex dcs1332] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1333.hex dcs1333] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1334.hex dcs1334] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1335.hex dcs1335] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1336.hex dcs1336] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1337.hex dcs1337] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1338.hex dcs1338] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1339.hex dcs1339]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1340.hex dcs1340] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1341.hex dcs1341] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1342.hex dcs1342] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1343.hex dcs1343] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1344.hex dcs1344] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1345.hex dcs1345] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1346.hex dcs1346] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1347.hex dcs1347] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1348.hex dcs1348] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1349.hex dcs1349]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1350.hex dcs1350] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1351.hex dcs1351] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1352.hex dcs1352] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1353.hex dcs1353] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1354.hex dcs1354] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1355.hex dcs1355] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1356.hex dcs1356] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1357.hex dcs1357] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1358.hex dcs1358] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1359.hex dcs1359]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1360.hex dcs1360] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1361.hex dcs1361] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1362.hex dcs1362] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1363.hex dcs1363] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1364.hex dcs1364] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1365.hex dcs1365] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1366.hex dcs1366] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1367.hex dcs1367] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1368.hex dcs1368] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1369.hex dcs1369]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1370.hex dcs1370] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1371.hex dcs1371] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1372.hex dcs1372] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1373.hex dcs1373] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1374.hex dcs1374] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1375.hex dcs1375] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1376.hex dcs1376] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1377.hex dcs1377] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1378.hex dcs1378] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1379.hex dcs1379]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1380.hex dcs1380] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1381.hex dcs1381] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1382.hex dcs1382] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1383.hex dcs1383] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1384.hex dcs1384] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1385.hex dcs1385] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1386.hex dcs1386] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1387.hex dcs1387] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1388.hex dcs1388] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1389.hex dcs1389]<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1390.hex dcs1390] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1391.hex dcs1391] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1392.hex dcs1392] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1393.hex dcs1393] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1394.hex dcs1394] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1395.hex dcs1395] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1396.hex dcs1396] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1397.hex dcs1397] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1398.hex dcs1398] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1399.hex dcs1399] [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs1400.hex dcs1400] a7ac8e268889ee7da1608b4e4c8d5cf2597b770f 0 4 1725 1721 2012-01-31T12:21:26Z Dfe002 7 /* Download Section */ added link to rcS file wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> '''2.9 (30.1.2012)'''<br> <ul> <li> Updated udhcpc <li> Updated rcS (udhcpc parameters, ntp timeserver, bootscript execution order) <li> modified nfsmount_all to only mount dcbrw and dcbro <li> added _S05restartreadback.sh, S27enable_ttcrx.sh, S31unsetOldMode.sh, S52startntp.sh to /etc/boot <li> removed S30rcu-conf.sh, S31setoldmode from /etc/boot <li> disabled CONFIG_DEBUG_SLAB in kernel </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <li>'''Version 2.9: '''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0031.hex hex file for dcs0031] | [[Firmware files for boards 30 - 1400]] | [http://web.ift.uib.no/~dominik/files/dcs_fw/rcS rcS file for new udhcpc, boot script order] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br> '''v 1.5 (17.08.2010)'''<br> <ul> <li>Fix done by Attiq Ur Rehman:<br> There is minor change in the "fifo wrapper":<br> Line #73 new signal cnt_dn<br> Line #91 comparison with "read_counter"<br> Line #170,172,174 check of possible logical conditions<br> This file was used for the RCU firmware (from 10th July and on wards) to fix the Erroneous behavior causing busy condition. </li> </ul> <br> '''v 1.6 (20.01.2012)'''<br> <ul> <li>Single l2 messages does not generate CDH</li> <li>Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register.</li> <li>Cleaned up code and removed commented lines (RoI is now gone)</li> <li>Minor changes to DAQ header error word</li> <li>New output: sync - software trigger decoded from RoC = 0xD</li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.5_source_files.rar Firmware v 1.5 - VHDL files, including testbench]<br> <br> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.6.pdf Specification/design document for Firmware version 1.6] (Updated 20.01.12) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.6_source_files.zip Firmware v 1.6 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool]. Note that version 9.0 gives errors when trying to program the FPGA. [ftp://ftp.actel.com/downloads/flashpro/FlashPro86.zip Version 8.6] is the last version that works for the Actel on the RCU.<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 407a3dd7876fef5eb0ca255d7f07a738014962e4 0 33 1726 1713 2012-02-01T12:13:38Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[http://www.edn.com/contents/images/46098.pdf 10 tips for generating reusable VHDL]] [[http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide]] [[http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer]] [[Category:Mikroelektronikk]] 263addc50e6ce36aa6805f668cee48b348967ca1 0 234 1727 1714 2012-02-01T12:15:01Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] a48a6fe92a1c1684afe73f4de0e9aef4d0257192 6 401 1728 2012-02-01T13:27:26Z Nfyal 26 All you need to know about susy with taus in ATLAS and mysteries hidden in 2010 ATLAS collision data wikitext text/x-wiki All you need to know about susy with taus in ATLAS and mysteries hidden in 2010 ATLAS collision data d94067337cf8f1ce5f99b412aa70492f4c5dd697 0 398 1729 1718 2012-02-02T13:45:50Z Kmo078 65 wikitext text/x-wiki ==Installing== To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' *If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' *If you run mac (tested on mac osx 10.6), the c++ and fortran compilers will not compile for the same architecture unless you preface configure command with ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. ==Compiling programs== To compile your own Fortran program written with DarkSusy, the call should be similar to (if you've configured with gfortran): ''gfortran -I$PWD/../include -L$PWD/../lib -o ProgramName ProgramName.f -ldarksusy -lFH -lHB'' For examples, one can look in the makefile in ''test''. [[Category:Installing]] 38002e420d58290a45278ce23e02138bfb083a4d 0 399 1730 1716 2012-02-02T14:59:03Z Sya081 50 wikitext text/x-wiki *Hardware requirements* * Focal read-out box * Computer with Gb network capability * One or more patch panels PCBs * One or more flex PCBs with mounted MIMOS ASICs *Software requirements and drivers* - Use Impact to configure FPGA(s) - start TFTP server - Use XMD: <pre> $ connect mb mdm -debugdevice devicenr 4 $ dow u-boot.elf </pre> Open serial console <pre> $ tftp </pre> Boot Linux kernel: <pre> $ bootm </pre> Adjust MAC address and load startup script: <pre> $ ifconfig eth0 hw ether 00:0a:35:02:4b:a8 $ udhcpc $ /home/test/load.sh </pre> 50f1dd49c295e91eae5062fbda316da2707a3dc5 1731 1730 2012-02-02T15:05:22Z Sya081 50 wikitext text/x-wiki ===Overview=== ==Hardware requirements== *Focal read-out box *Computer with Gb network capability *One or more patch panels PCBs *One or more flex PCBs with mounted MIMOS ASICs ==Software requirements and drivers== ==Using Xilinx Impact to configure FPGA(s)== How-TO ==Configure TFTP server== How-To - Use XMD: $ connect mb mdm -debugdevice devicenr 4 $ dow u-boot.elf Open serial console <pre> $ tftp </pre> Boot Linux kernel: <pre> $ bootm </pre> Adjust MAC address and load startup script: <pre> $ ifconfig eth0 hw ether 00:0a:35:02:4b:a8 $ udhcpc $ /home/test/load.sh </pre> c592ffd9ce6484a6ece496fb83256ba17ff3b911 1732 1731 2012-02-02T15:11:25Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Computer with Gb network capability *One or more patch panels PCBs *One or more flex PCBs with mounted MIMOS ASICs ==Software requirements and drivers== ==Configure the FPGA(s)== ===Using XMD=== How-to ===Using Impact=== How-TO ==Configure TFTP server== How-To ==Connect to debug module on Processor Bus== - Use XMD: $ connect mb mdm -debugdevice devicenr 4 $ dow u-boot.elf Open serial console $ tftp Boot Linux kernel: <pre> $ bootm </pre> Adjust MAC address and load startup script: <pre> $ ifconfig eth0 hw ether 00:0a:35:02:4b:a8 $ udhcpc $ /home/test/load.sh </pre> - Use XMD: $ connect mb mdm -debugdevice devicenr 4 $ dow u-boot.elf 5005c7cf0ff391f32d0e3485685fe79a34231634 1733 1732 2012-02-03T09:53:48Z Sya081 50 Newly added. wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Computer with Gb network capability *One or more patch panels PCBs *One or more flex PCBs with mounted MIMOS ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD can be called from SDK or a normal cmd command window, we need to set up the path environment firstly with the settings32.bat(settings64.bat for a 64 bit PC) file from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", copy it to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6_u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6_u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Connect to debug module on Processor Bus== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), set with Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> All of the above configurations can be put into a single initiative script file. Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> Run the client side DAQ software: <pre> ~ # /home/uib/focal </pre> [[Category:focal]] da943748ce88cfb7d3565b3ada44dda9cdc05f9d 1734 1733 2012-02-03T10:01:10Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Computer with Gb network capability *One or more patch panels PCBs *One or more flex PCBs with mounted MIMOS ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD can be called from SDK or a normal cmd command window, we need to set up the path environment firstly with the settings32.bat(settings64.bat for a 64 bit PC) file from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", copy it to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6_u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6_u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Connect to debug module on Processor Bus== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), set with Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> All of the above configurations can be put into a single initiative script file. Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> Run the client side DAQ software: <pre> ~ # /home/uib/focal </pre> Start the server side DAQ software: <pre> $ ./server </pre> [[Category:Focal]] cfd3386941452bcd38236236ed1a3d3fac0cff24 1735 1734 2012-02-03T10:09:04Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for data taking *Windows PC for software/firmware debugging *One or more patch panels PCBs *One or more flex PCBs with mounted MIMOS ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD can be called from SDK or a normal cmd command window, we need to set up the path environment firstly with the settings32.bat(settings64.bat for a 64 bit PC) file from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", copy it to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6_u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6_u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Connect to debug module on Processor Bus== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), set with Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> All of the above configurations can be put into a single initiative script file. Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> Run the client side DAQ software: <pre> ~ # /home/uib/focal </pre> Start the server side DAQ software: <pre> $ ./server </pre> [[Category:Focal]] df12fb4fa9778741e2ed5a4a987d84923b9ecc50 1736 1735 2012-02-03T10:09:35Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for data taking *Windows PC for software/firmware debugging *One or more patch panels PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD can be called from SDK or a normal cmd command window, we need to set up the path environment firstly with the settings32.bat(settings64.bat for a 64 bit PC) file from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", copy it to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6_u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6_u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Connect to debug module on Processor Bus== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), set with Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> All of the above configurations can be put into a single initiative script file. Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> Run the client side DAQ software: <pre> ~ # /home/uib/focal </pre> Start the server side DAQ software: <pre> $ ./server </pre> [[Category:Focal]] e5821ba35cf3349687826c62366ffb72eb5e8d18 1743 1736 2012-02-16T11:31:44Z Sya081 50 Added some text about petalinux operations and so on. wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Connect to debug module on Processor Bus== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 1 bit for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 1 bit for 1 chip [23 downto 0], HEX 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX Notes: * Only the values are allow to change, but don't change the number of digits, at least don't increase. * All configuration values start from the first non-space character of a new line and end before the first space. * No empty lines are allowed before the end of all configuration values. </pre> ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Four Mimosa chips in one detector layer share the same JTAG interface, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. ===Threshold voltages setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. [[Category:Focal]] 7f2a847d7f2076a289aac543fd5b83c583ecf214 1744 1743 2012-02-16T11:43:52Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Connect to debug module on Processor Bus== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 1 bit for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 1 bit for 1 chip [23 downto 0], HEX 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Four Mimosa chips in one detector layer share the same JTAG interface, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. ===Threshold voltages setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. [[Category:Focal]] 51b8354f28c4f40c5bcfdba6f6cf04adfaf280ed 1745 1744 2012-02-16T11:49:10Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Connect to debug module on Processor Bus== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 1 bit for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 1 bit for 1 chip [23 downto 0], HEX 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: 1~6 for detector layer 1 to 6, 7 for all. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. ===Threshold voltages setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. [[Category:Focal]] 920e41a65735d4f788c1ca2786dd558b7d006b51 1746 1745 2012-02-16T12:38:01Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 1 bit for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 1 bit for 1 chip [23 downto 0], HEX 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: 1~6 for detector layer 1 to 6, 7 for all. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. [[Category:Focal]] a7e7e6203d92ac4a40cb02ff6e84d63ede047a51 1748 1746 2012-02-16T12:43:54Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 1 bit for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 1 bit for 1 chip [23 downto 0], HEX 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st chip as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: 1~6 for detector layer 1 to 6, 7 for all. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. [[Category:Focal]] 1b68d61e42c6192ded56520e736de545a3b5f943 1749 1748 2012-02-17T14:19:37Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: 1~6 for detector layer 1 to 6, 7 for all. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. [[Category:Focal]] 445ce6bdbdee01fa2863aa42f30789f5bc873c34 1750 1749 2012-02-17T15:44:16Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. [[Category:Focal]] 2d0ff96ab12dd2c4fb8b847129f9bd7a4733da0e 1751 1750 2012-02-17T15:53:46Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. [[Category:Focal]] bf64b40cce076981ff28ecbbf2d4fdb90f676cd1 1752 1751 2012-02-22T13:58:44Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. [[Category:Focal]] ba3dc418bfcb627444ee7e9b2fcda6817fd7ace0 1753 1752 2012-02-23T16:01:59Z Sya081 50 Added descriptions of the steps for buring the FPGA configuration files and u-boot/linux images into the on-board flashes. wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 OFF (EXT_CCLK = 0) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> [[Category:Focal]] dbdf64c0106a5ba0cf88433739d6d2089cb1d1db 1754 1753 2012-02-23T16:02:51Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, don't care here 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 OFF (EXT_CCLK = 0) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> [[Category:Focal]] 3cd9cb4ee71e6cdde83627ec03f9861f6d18ab97 1755 1754 2012-02-23T16:12:36Z Sya081 50 wikitext text/x-wiki ==Overview== ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> For the switch setups, please refer to [http://www.xilinx.com/support/documentation/boards_and_kits/ug534.pdf ML605 Hardware User Guide]. ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, don't care here 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 OFF (EXT_CCLK = 0) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> ==Useful links== # [http://www.xilinx.com/support/documentation/boards_and_kits/ug533.pdf Getting Started with the Xilinx Virtex-6 FPGA ML605 Evaluation Kit] # [http://www.xilinx.com/support/documentation/boards_and_kits/xtp055.pdf ML605 Restoring Flash Contents] # [http://www.xilinx.com/support/documentation/user_guides/ug360.pdf Virtex-6 FPGA Configuration User Guide] [[Category:Focal]] b35fba02596def55c45217a6cf70b46d34ea8d45 1758 1755 2012-02-23T16:40:00Z Sya081 50 wikitext text/x-wiki ==Overview== This page contains step by step informations to setup the Focal readout electronics for MAPS detectors. ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> For the switch setups, please refer to [http://www.xilinx.com/support/documentation/boards_and_kits/ug534.pdf ML605 Hardware User Guide]. ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, don't care here 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 OFF (EXT_CCLK = 0) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> ==Useful links== # [http://www.xilinx.com/support/documentation/boards_and_kits/ug533.pdf Getting Started with the Xilinx Virtex-6 FPGA ML605 Evaluation Kit] # [http://www.xilinx.com/support/documentation/boards_and_kits/xtp055.pdf ML605 Restoring Flash Contents] # [http://www.xilinx.com/support/documentation/user_guides/ug360.pdf Virtex-6 FPGA Configuration User Guide] [[Category:Focal]] 59d2d6bd3f46d6eebfbbdac59a769e9f6fd566ce 0 331 1737 1706 2012-02-06T12:49:17Z Kmo078 65 Added a link to ISAJET installation tips wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 05636013c26e213b4f85dced9232b8ebef8e07dd 1763 1737 2012-02-24T10:50:37Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] * [[Useful papers]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] dffb842ce2f4cb8ad39aea8d792d5cdeac9d5e4c 1765 1763 2012-02-24T10:53:30Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] ccd4df3b64e158685525664d7f772b49dabf36f8 1766 1765 2012-02-24T10:54:12Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[Starting with CTA]] * [[Starting with ATLAS]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] a2027f7ac90cd462cd7390387f283aadb7085520 1767 1766 2012-02-24T10:54:40Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[Starting with CTA]] * [[Starting with ATLAS]] * [[CTA information]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 1b7fb68b823c2ea1c47969b4c13308dc62120ded 1768 1767 2012-02-24T10:55:34Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] - how to get started with CTA * [[ATLA information]] - how to get started with ATLAS == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 1a27c3175dc7f51ad07bda4e0f7cbbd7ad24cc9c 1769 1768 2012-02-24T10:56:21Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] * [[ATLA information]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 9faa13f623834a1dd3fec421582fb22121fc4d1b 1770 1769 2012-02-24T10:56:30Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] * [[ATLAS information]] == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 02a44a5e0396815eb96432a8bbc8c5e2d79bb22c 1771 1770 2012-02-24T10:57:10Z Hsa061 18 wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] (how to get accounts, get on lists and access) * [[ATLAS information]] (how to get accounts, get on lists and access) == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] a0dd4e981b6407ba5a63e5ed49ce59280f31b720 0 402 1738 2012-02-06T12:54:14Z Kmo078 65 Created a page with installation experience w/ ISAJET wikitext text/x-wiki First, install ypatchy on your computer. On my mac, fink install patchy works. Then, download [http://www.nhn.ou.edu/~isajet/isajet.car isajet.car] , [http://www.nhn.ou.edu/~isajet/Makefile Makefile] and [http://www.nhn.ou.edu/~isajet/isared.tar.gz isared.tar.gz] . All are found on the [http://www.nhn.ou.edu/~isajet/isared.tar.gz ISAJET site] . Put them in a folder where you want to install them, and run uncompress isared.tar.gz . Now you need to edit the makefile with the correct paths to ypatchy and your fortran compiler. An example for a mac installation may be found [http://people.uib.no/kmo078/Documents/Makefile here]. Lastly, run make isatools (takes time) and make to install isajet. 439bfcbc62286598ee0b9268b8dd15d3cd350369 1739 1738 2012-02-06T12:54:39Z Kmo078 65 wikitext text/x-wiki First, install ypatchy on your computer. On my mac, fink install patchy works. Then, download [http://www.nhn.ou.edu/~isajet/isajet.car isajet.car] , [http://www.nhn.ou.edu/~isajet/Makefile Makefile] and [http://www.nhn.ou.edu/~isajet/isared.tar.gz isared.tar.gz] . All are found on the [http://www.nhn.ou.edu/~isajet/isared.tar.gz ISAJET site] . Put them in a folder where you want to install them, and run uncompress isared.tar.gz . Now you need to edit the makefile with the correct paths to ypatchy and your fortran compiler. An example for a mac installation may be found [http://people.uib.no/kmo078/Documents/Makefile here]. Lastly, run make isatools (takes time) and make to install isajet. 9359b26909589fbddc83d78e2c21ebdf61b7f0da 0 36 1740 1131 2012-02-06T15:18:30Z Nfyku 4 Oppdatert til Quartus 11.1 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== mentor precision Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone III med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] a01df9237a566e92546d5d4f2ade317ed2c5e8c8 1741 1740 2012-02-06T15:19:15Z Nfyku 4 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== mentor precision Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte opp dette skriv: presision i eit terminalvindu. Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone III med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] dbbc7f275285fe410b449d79ebec6cb7afa573c1 1742 1741 2012-02-07T08:39:51Z Nfyku 4 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte synteseprogrammet: precision Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone III med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 27f3f4b6a421c7e11bf702ffd37248e2352105ba 6 403 1747 2012-02-16T12:40:00Z Sya081 50 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 317 1756 1715 2012-02-23T16:24:41Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== The software driver for the message buffer system can be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-dcs/trunk/rculinux/dcscMsgBufferInterface/ [[Setting Up PetaLinux System]] Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk petalinux_sdk] [[Get readout box up and running]] == Download section == #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 [[Category:Mikroelektronikk]] 144ce9502417d193ecdcf80546acb6b403238110 1757 1756 2012-02-23T16:36:34Z Sya081 50 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== * [[Setting Up PetaLinux System]] * Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk petalinux_sdk] * [[Get readout box up and running]] * [[Programming Mimosa chips]] == Shopping list == 1x 2U 335mm Rack mount enclosure, Grey - 665-7712 - 556,29<br> 1x RD-125A Switch Mode PSU, 5V/15A,12V/10A - 644-6941 - 662,16<br> 3x DC/DC PoL,DOSA,2.4-5.5Vin,0.75-3.3Vo 6A - 150-758 - 116,16<br> 1x 4.20mm,housing,MiniFit,receptacle,DR,6w, - 679-5773 - 2,064<br> http://www.samtec.com/search/vita57fmc.aspx<br> 1x BULGIN - BZH01/Z0000/11 - INLET, IEC, SWITCHED, RED - F9997237 - 57,39<br> 1x MH CONNECTORS - MH3101S-8821 - COUPLER, RJ45, SHIELDED - F1122292 - 92,11<br> 12x TYCO ELECTRONICS / AMP - 5569262-1 - JACK, RJ45, MULTI PORT, 2X4 - F1162485 - 102,42<br> 2x L-COM - ECF504B-UAB - Modular Coupler - F1702375 - 91,31<br> 2x USB cables - F1076669 - F1308878 [[Category:Mikroelektronikk]] 7b0409dd47e0ad47e56ef532a6183fe4973af75d 0 404 1759 2012-02-23T17:17:13Z Sya081 50 New page. more to be added. wikitext text/x-wiki ==Overview== The system uses a C progarm named xsvfPlayer to read in JTAG configurations from an xsvf format binary file, and set up the JTAG pins to configure the front-end Mimosa chips. The xsvf binary file is generated from a readable text format svf file with Xilinx SVF-to-XSVF Writer - svf2xsvf. In our system, we need to configure about 100 mimosa chips with different threshold voltages and other settings, sometime we also need to change these values online, it's not practical to generate a xsvf file for every chip. Instead, it's possible to have a template xsvf file and hack into this file to modify the corresponded byte values for every chip. So we need to know some fundamental informations of the xsvf file. ==Multi-device JTAG chain== Normally when we want to access one of the devices in the JTAG chain with more than one device, we need to bypass all the others. When those devices are bypassed, they just connect their 1-bit bypass registers into the JTAG chain, it looks as belwo for the 1st chip in a 4-chip JTAG chain: <pre> _______chip1________ _2_ _3_ _4_ TDI --> |0|1|..........|127| --> |0| -> |0| -> |0| -> TDO -------------------- --- --- --- </pre> The JTAG bypass command is the one with all 1s for all command bits, and normally we can write zeros to the bypass registers. ==Useful Links== #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] [[Category:Focal]] 2c4abc660586a90117954bc7c6f0a1cc6d4a4139 1760 1759 2012-02-23T17:18:04Z Sya081 50 wikitext text/x-wiki ==Overview== The system uses a C progarm named xsvfPlayer to read in JTAG configurations from an xsvf format binary file, and set up the JTAG pins to configure the front-end Mimosa chips. The xsvf binary file is generated from a readable text format svf file with Xilinx SVF-to-XSVF Writer - svf2xsvf. In our system, we need to configure about 100 mimosa chips with different threshold voltages and other settings, sometime we also need to change these values online, it's not practical to generate a xsvf file for every chip. Instead, it's possible to have a template xsvf file and hack into this file to modify the corresponded byte values for every chip. So we need to know some fundamental informations of the xsvf file. ==Multi-device JTAG chain== Normally when we want to access one of the devices in the JTAG chain with more than one device, we need to bypass all the others. When those devices are bypassed, they just connect their 1-bit bypass registers into the JTAG chain, it looks as below for the 1st chip in a 4-chip JTAG chain: <pre> _______chip1________ _2_ _3_ _4_ TDI --> |0|1|..........|127| --> |0| -> |0| -> |0| -> TDO -------------------- --- --- --- </pre> The JTAG bypass command is the one with all 1s for all command bits, and normally we can write zeros to the bypass registers. ==Useful Links== #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] [[Category:Focal]] 9b61675d1c20570987d3ae132c35ce8264268f23 1761 1760 2012-02-23T18:03:15Z Sya081 50 wikitext text/x-wiki ==Overview== The system uses a C progarm named xsvfPlayer to read in JTAG configurations from an xsvf format binary file, and set up the JTAG pins to configure the front-end Mimosa chips. The xsvf binary file is generated from a readable text format svf file with Xilinx SVF-to-XSVF Writer - svf2xsvf. In our system, we need to configure about 100 mimosa chips with different threshold voltages and other settings, sometime we also need to change these values online, it's not practical to generate a xsvf file for every chip. Instead, it's possible to have a template xsvf file and hack into this file to modify the corresponded byte values for every chip. So we need to know some fundamental informations of the xsvf file. ==Multi-device JTAG chain== Normally when we want to access one of the devices in a JTAG chain with more than one device, we need to bypass all the others. When those devices are bypassed, they just connect their 1-bit bypass registers into the JTAG chain, it looks as below for the 1st chip in a 4-chip JTAG chain: <pre> _______chip1________ _2_ _3_ _4_ TDI --> |0|1|..........|127| --> |0| -> |0| -> |0| -> TDO -------------------- --- --- --- </pre> The JTAG bypass command is the one with all 1s for all command bits, and normally we can write zeros to the bypass registers. Instead of adding bypass commands and all bypass register bits for every JTAG commands, there are header and trailer commands used to tell the JTAG controller to automatically add some header/trailer bits for instructions and data. TIR/HIR/TDR/HDR are the SVF header and trailer instructions, for Mimosa chips which have 5-bit commands, the 1st chip in a 4-chip JTAG chain should have a header/trailer setting like this: <pre> TIR 0 ; // No trailer in command HIR 15 TDI (7fff) SMASK (7fff) ; // 15 bits of bypass commands(all 1s) ahead of every command for the other 3 chips TDR 0 ; // No trailer in data HDR 3 TDI (00) SMASK (00) ; // 3 bits of 0s ahead of every data output for the three bypass registers. </pre> ==SVF to XSVF== If we want to configure the 128-bit DAC register of the second Mimosa chip, normally we use svf commands like: <pre> TIR 5 TDI (1f) SMASK (1f) ; // 5 bits bypass command for chip1 HIR 10 TDI (3ff) SMASK (3ff) ; // 10 bits bypass commands for chip3 and chip4; TDR 1 TDI (00) SMASK (00) ; // 1 bit for bypass register of chip1 HDR 2 TDI (00) SMASK (00) ; // 2 bits for bypass registers of chip3 and chip4 SIR 5 TDI (0F) SMASK(1F); // command: setting BIAS_DAC(0x0F) SDR 128 TDI (64327676202076763220280a0a0a0a64); // 128 bit output data, without input check. </pre> After conversion we can get a text format xsvf file with commands as below: <pre> XREPEAT(07) 0x20 XRUNTEST(04) 0x00000000 XSIR(02) 0x14 0x0fbfff XSDRSIZE(08) 0x00000083 XTDOMASK(01) 0x0000000000000000000000000000000000 XSDRTDO(09) 0x0190c9d9d88081d9d8c880a02828282990 0x0000000000000000000000000000000000 XCOMPLETE(00) </pre> Notes: the numbers in bracket are the codes for the corresponded commands. Dump of the binary format xsvf file: <pre> 00000000h: 07 20 04 00 00 00 00 02 14 0F BF FF 08 00 00 00 00000010h: 83 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020h: 00 00 00 09 01 90 C9 D9 D8 80 81 D9 D8 C8 80 A0 00000030h: 28 28 28 29 90 00 00 00 00 00 00 00 00 00 00 00 00000040h: 00 00 00 00 00 00 00 </pre> ==Descriptions of xsvf file== Firstly specify the XREPEAT value, which is the number of times that TDO is tested against the expected value before a failure is issued: <pre> XREPEAT(07) 0x20 </pre> then specify the number of TCK cycles to be applied in the Run-Test/Idle state after the end of one instruction/data command: <pre> XRUNTEST(04) 0x00000000 </pre> the instruction becomes: 5 bits of bypass command 0x1F for chip1, 5 bits of 0x0F and two other five bits of 0x1F = b'11111011111111111111 = 0x0fbfff; <pre> XSIR(02) 0x14 0x0fbfff //0x14 is the number of instruction bits. </pre> then follows with the number of data bits: <pre> XSDRSIZE(08) 0x00000083 //128 bits + 3 bypass bits. </pre> here we don't check the TDO out, so TDOMASK is set to all 0s: <pre> XTDOMASK(01) 0x0000000000000000000000000000000000 </pre> shift out the number of bit as specified above, the value is added with one 0 at the begining and two 0s at the end: b'0 + 0x64327676202076763220280a0a0a0a64 + b'00 = 0x0190c9d9d88081d9d8c880a02828282990, compare the TDO value with the second argument, here we don't check, the second parameter is filled with all 0s. <pre> XSDRTDO(09) 0x0190c9d9d88081d9d8c880a02828282990 0x0000000000000000000000000000000000 </pre> finish the operation: <pre> XCOMPLETE(00) </pre> ==Programming Mimosa chips== To be added. ==Useful Links== #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] [[Category:Focal]] 67660d3f5a30d0b26197a119e13b408ca89f9b1c 1762 1761 2012-02-23T18:14:25Z Sya081 50 wikitext text/x-wiki ==Overview== The system uses a C progarm named xsvfPlayer to read in JTAG configurations from an xsvf format binary file, and set up the JTAG pins to configure the front-end Mimosa chips. The xsvf binary file is generated from a readable text format svf file with Xilinx SVF-to-XSVF Writer - svf2xsvf. In our system, we need to configure about 100 mimosa chips with different threshold voltages and other settings, sometime we also need to change these values online, it's not practical to generate a xsvf file for every chip. Instead, it's possible to have a template xsvf file and hack into this file to modify the corresponded byte values for every chip. So we need to know some fundamental informations of the xsvf file. ==Multi-device JTAG chain== Normally when we want to access one of the devices in a JTAG chain with more than one device, we need to bypass all the others. When those devices are bypassed, they just connect their 1-bit bypass registers into the JTAG chain, it looks as below for the 1st chip in a 4-chip JTAG chain: <pre> _______chip1________ _2_ _3_ _4_ TDI --> |0|1|..........|127| --> |0| -> |0| -> |0| -> TDO -------------------- --- --- --- </pre> The JTAG bypass command is the one with all 1s for all command bits, and normally we can write zeros to the bypass registers. Instead of adding bypass commands and all bypass register bits for every JTAG commands, there are header and trailer commands used to tell the JTAG controller to automatically add some header/trailer bits for instructions and data. TIR/HIR/TDR/HDR are the SVF header and trailer instructions, for Mimosa chips which have 5-bit commands, the 1st chip in a 4-chip JTAG chain should have a header/trailer setting like this: <pre> TIR 0 ; // No trailer in command HIR 15 TDI (7fff) SMASK (7fff) ; // 15 bits of bypass commands(all 1s) ahead of every command for the other 3 chips TDR 0 ; // No trailer in data HDR 3 TDI (00) SMASK (00) ; // 3 bits of 0s ahead of every data output for the three bypass registers. </pre> ==SVF to XSVF== If we want to configure the 128-bit DAC register of the second Mimosa chip, normally we use svf commands like: <pre> TIR 5 TDI (1f) SMASK (1f) ; // 5 bits bypass command for chip1 HIR 10 TDI (3ff) SMASK (3ff) ; // 10 bits bypass commands for chip3 and chip4; TDR 1 TDI (00) SMASK (00) ; // 1 bit for bypass register of chip1 HDR 2 TDI (00) SMASK (00) ; // 2 bits for bypass registers of chip3 and chip4 SIR 5 TDI (0F) SMASK(1F); // command: setting BIAS_DAC(0x0F) SDR 128 TDI (64327676202076763220280a0a0a0a64); // 128 bit output data, without input check. </pre> After conversion we can get a text format xsvf file with commands as below: <pre> XREPEAT(07) 0x20 XRUNTEST(04) 0x00000000 XSIR(02) 0x14 0x0fbfff XSDRSIZE(08) 0x00000083 XTDOMASK(01) 0x0000000000000000000000000000000000 XSDRTDO(09) 0x0190c9d9d88081d9d8c880a02828282990 0x0000000000000000000000000000000000 XCOMPLETE(00) </pre> Notes: the numbers in bracket are the codes for the corresponded commands. Dump of the binary format xsvf file: <pre> 00000000h: 07 20 04 00 00 00 00 02 14 0F BF FF 08 00 00 00 00000010h: 83 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020h: 00 00 00 09 01 90 C9 D9 D8 80 81 D9 D8 C8 80 A0 00000030h: 28 28 28 29 90 00 00 00 00 00 00 00 00 00 00 00 00000040h: 00 00 00 00 00 00 00 </pre> ==Descriptions of xsvf file== Firstly specify the XREPEAT value, which is the number of times that TDO is tested against the expected value before a failure is issued: <pre> XREPEAT(07) 0x20 </pre> then specify the number of TCK cycles to be applied in the Run-Test/Idle state after the end of one instruction/data command: <pre> XRUNTEST(04) 0x00000000 </pre> the instruction becomes: 5 bits of bypass command 0x1F for chip1, 5 bits of 0x0F and two other five bits of 0x1F = b'11111011111111111111 = 0x0fbfff; <pre> XSIR(02) 0x14 0x0fbfff //0x14 is the number of instruction bits. </pre> then follows with the number of data bits: <pre> XSDRSIZE(08) 0x00000083 //128 bits + 3 bypass bits. </pre> here we don't check the TDO out, so TDOMASK is set to all 0s, with 0s being added at the beginning(17 bytes): <pre> XTDOMASK(01) 0x0000000000000000000000000000000000 </pre> shift out the number of bits as specified above, the value is added with one 0 at the begining and two 0s at the end: b'0 + 0x64327676202076763220280a0a0a0a64 + b'00 = 0x0190c9d9d88081d9d8c880a02828282990, compare the TDO value with the second argument, here we don't check, it is filled with all 0s. 0s being added to these two numbers at the beginning(17 bytes): <pre> XSDRTDO(09) 0x0190c9d9d88081d9d8c880a02828282990 0x0000000000000000000000000000000000 </pre> finish the operation: <pre> XCOMPLETE(00) </pre> ==Programming Mimosa chips== To be added. ==Useful Links== #[[Media:svf_specification.pdf|Serial Vector Format(SVF) Specification]] #[[Media:svf_xilinx.pdf|SVF and XSVF File Formats for Xilinx Devices]] [[Category:Focal]] 38d3430f5614f6b5f313589342a57815032f3009 0 405 1764 2012-02-24T10:51:26Z Hsa061 18 Created page with ' Astroparticle ----------------------- * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf' wikitext text/x-wiki Astroparticle ----------------------- * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf 6eb11be726c62cb095760fcee3a3463af39728d8 0 139 1772 1691 2012-02-24T11:24:33Z Nfyal 26 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 10p course. Active attendance will be one of the requirements for the students. Planned 2010 subjects include: * New master student project proposals * SUSY seminars by Per Osland * ATLAS technical tutorials * LHC updates * Possible some invited speakers == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] fbeddc86c69135425668220f4275288fa4fee9bd 6 406 1773 2012-02-24T11:26:00Z Nfyal 26 Review of ATLAS analysis and computing structures, seen from UiB wikitext text/x-wiki Review of ATLAS analysis and computing structures, seen from UiB 45e6871a338d1bbf2aff2326ae52d2b04f2b3f39 0 139 1774 1772 2012-02-24T11:29:01Z Nfyal 26 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 5p course. Active attendance will be one of the requirements for the students. In 2011 the seminars were given by W.Liebig in a form of a short course. == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] e9fc4b8fc6564f09366cf6edf11b67bb6c69724e 1775 1774 2012-02-24T11:48:50Z Nfyal 26 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 5p course. Active attendance will be one of the requirements for the students. In 2011 the seminars were given by W.Liebig in a form of a short course. == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] Talks from Bergen in CERN indico (some of them visible only for ATLAS or ALICE members)<br> *[https://indico.cern.ch/search.py?categId=0&p=bergen&f=&collections=&startDate=&endDate=&sortField=&sortOrder=d] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] b7d98fad0dd5f46f4419497dfdb3e17eb721c798 1776 1775 2012-02-24T11:49:38Z Nfyal 26 wikitext text/x-wiki == Seminar information == Our seminar time is (some) wednesdays at 14:15, usually the seminars are in room 316. Seminars will be announced on the IFT-Particle-Seminar list. The LHC seminars are part of the "advanced LHC instrumentation" special pensum 5p course. Active attendance will be one of the requirements for the students. In 2011 the seminars were given by W.Liebig in a form of a short course. == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] Talks from Bergen in CERN indico (some of them visible only for ATLAS or ALICE members)<br> * Talks and events from UiB at CERN [https://indico.cern.ch/search.py?categId=0&p=bergen&f=&collections=&startDate=&endDate=&sortField=&sortOrder=d] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] bc5f3e24153ac72da58a83f59915e3482087cca9 0 399 1777 1758 2012-03-01T09:27:11Z Sya081 50 wikitext text/x-wiki ==Overview== This page contains step by step informations to setup the Focal readout electronics for MAPS detectors. ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> For the switch setups, please refer to [http://www.xilinx.com/support/documentation/boards_and_kits/ug534.pdf ML605 Hardware User Guide]. ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, don't care here 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 OFF (EXT_CCLK = 0) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> ==LED definitions== * D1: on: Test pattern out mode (mode 2) of Spartan1, off: normal mode; * D2: on: All enabled channels have correct patterns, off: at least one channel(1/4 of a chip) of pattern mismatch; * D3: flash: 1Hz from Spartan1 to Spartan2, maybe soldered up side down for some boxes; * D4: As D1, for Spartan2; * D5: As D2, for Spartan2; ==Useful links== # [http://www.xilinx.com/support/documentation/boards_and_kits/ug533.pdf Getting Started with the Xilinx Virtex-6 FPGA ML605 Evaluation Kit] # [http://www.xilinx.com/support/documentation/boards_and_kits/xtp055.pdf ML605 Restoring Flash Contents] # [http://www.xilinx.com/support/documentation/user_guides/ug360.pdf Virtex-6 FPGA Configuration User Guide] [[Category:Focal]] 2e45251a7764a7bc207faa29c35bbd0655bb6165 1778 1777 2012-03-01T11:03:49Z Sya081 50 wikitext text/x-wiki ==Overview== This page contains step by step informations to setup the Focal readout electronics for MAPS detectors. ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ===Startup scripts=== For the automatic running of the user initialization scripts, you can't add them directly to the romfs script files like /etc/rc.sysinit, because there files are generated every time during Petalinux compilation and all custom modification will be overwritten. The source files for these initialization scrips are located in "~petalinux-dist/user/sys_init/data/etc/rc", normally you should put your custom startup commands in "start" file, but according to the Makefile, this file doesn't work properly at the moment, so we add our scripts to the end of "sysinit" file: <pre> echo "Running user init scripts." /home/test/init.sh </pre> After running "make romfs", you will find that these scripts are added into the romfs file "/etc/rc.sysinit". ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: b'00=chip1(J10); b'10=chip2(J11); b'01=chip3(J13); b'11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> For the switch setups, please refer to [http://www.xilinx.com/support/documentation/boards_and_kits/ug534.pdf ML605 Hardware User Guide]. ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, don't care here 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 OFF (EXT_CCLK = 0) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> ==LED definitions== * D1: on: Test pattern out mode (mode 2) of Spartan1, off: normal mode; * D2: on: All enabled channels have correct patterns, off: at least one channel(1/4 of a chip) of pattern mismatch; * D3: flash: 1Hz from Spartan1 to Spartan2, maybe soldered up side down for some boxes; * D4: As D1, for Spartan2; * D5: As D2, for Spartan2; ==Useful links== # [http://www.xilinx.com/support/documentation/boards_and_kits/ug533.pdf Getting Started with the Xilinx Virtex-6 FPGA ML605 Evaluation Kit] # [http://www.xilinx.com/support/documentation/boards_and_kits/xtp055.pdf ML605 Restoring Flash Contents] # [http://www.xilinx.com/support/documentation/user_guides/ug360.pdf Virtex-6 FPGA Configuration User Guide] [[Category:Focal]] e8b752610b6d0483d1acda2d84444170cb3b4e84 1779 1778 2012-03-01T15:49:17Z Sya081 50 wikitext text/x-wiki ==Overview== This page contains step by step informations to setup the Focal readout electronics for MAPS detectors. ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ===Startup scripts=== For the automatic running of the user initialization scripts, you can't add them directly to the romfs script files like /etc/rc.sysinit, because there files are generated every time during Petalinux compilation and all custom modification will be overwritten. The source files for these initialization scrips are located in "~petalinux-dist/user/sys_init/data/etc/rc", normally you should put your custom startup commands in "start" file, but according to the Makefile, this file doesn't work properly at the moment, so we add our scripts to the end of "sysinit" file: <pre> echo "Running user init scripts." /home/test/init.sh </pre> After running "make romfs", you will find that these scripts are added into the romfs file "/etc/rc.sysinit". ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: 0b00=chip1(J10); 0b10=chip2(J11); 0b01=chip3(J13); 0b11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> For the switch setups, please refer to [http://www.xilinx.com/support/documentation/boards_and_kits/ug534.pdf ML605 Hardware User Guide]. ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, don't care here 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 OFF (EXT_CCLK = 0) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> ==LED definitions== * D1: on: Test pattern out mode (mode 2) of Spartan1, off: normal mode; * D2: on: All enabled channels have correct patterns, off: at least one channel(1/4 of a chip) of pattern mismatch; * D3: flash: 1Hz from Spartan1 to Spartan2, maybe soldered up side down for some boxes; * D4: As D1, for Spartan2; * D5: As D2, for Spartan2; ==Useful links== # [http://www.xilinx.com/support/documentation/boards_and_kits/ug533.pdf Getting Started with the Xilinx Virtex-6 FPGA ML605 Evaluation Kit] # [http://www.xilinx.com/support/documentation/boards_and_kits/xtp055.pdf ML605 Restoring Flash Contents] # [http://www.xilinx.com/support/documentation/user_guides/ug360.pdf Virtex-6 FPGA Configuration User Guide] [[Category:Focal]] c3a574449ba759b643e5c7feec31f87d44cba0a1 0 398 1780 1729 2012-03-12T08:55:00Z Kmo078 65 Added installation of exclusion routines wikitext text/x-wiki ==Installing== To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' *If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' *If you run mac (tested on mac osx 10.6), the c++ and fortran compilers will not compile for the same architecture unless you preface configure command with ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. ==Compiling programs== To compile your own Fortran program written with DarkSusy, the call should be similar to (if you've configured with gfortran): ''gfortran -I$PWD/../include -L$PWD/../lib -o ProgramName ProgramName.f -ldarksusy -lFH -lHB'' For examples, one can look in the makefile in ''test''. ==Making your own exclusion routines== To make your own exclusion routine, it is good to start with ''dsacbnd9.f'' in ''darksusy-x.y.z/src/ac''. Copy this into your run directory, and change the name to, for example ''dsacbndX.f where ''X'' may not be 0-9, since these are in use. Make sure to change the name on the first line in the file as well. Now you may call: ''call dsacbndX'' in your DarkSusy code as ''dsmain'' demonstrates. ''gfortran -I$PWD/../include -L$PWD/../lib -o ProgramName ProgramName.f dsacbndX.f -ldarksusy -lFH -lHB'' [[Category:Installing]] 5d269bde8467a0feb8922695cde07c01d80afac7 1781 1780 2012-03-12T08:56:06Z Kmo078 65 wikitext text/x-wiki ==Installing== To install DarkSusy, make sure to download both the latest version and the galprop patch from the DarkSusy [http://www.physto.se/~edsjo/darksusy/ page]. Unpack darksusy-5.0.5.tar.gz, and move the patch into the resulting folder(darksusy-5.0.5). Now, unpack the patch as well with: ''tar zxvf galprop-patch.tar.gz'' *If you are running linux, run ''./configure'' if you wish to compile with g77 or ''./conf.gfortran'' for gfortran, then ''make'' and ''sudo make install'' *If you run mac (tested on mac osx 10.6), the c++ and fortran compilers will not compile for the same architecture unless you preface configure command with ''CFLAGS="-m32"''. In the end, move to the ''test'' directory, and run ''./dstest''. You should receive output similar to the file ''dstest.output''. ==Compiling programs== To compile your own Fortran program written with DarkSusy, the call should be similar to (if you've configured with gfortran): ''gfortran -I$PWD/../include -L$PWD/../lib -o ProgramName ProgramName.f -ldarksusy -lFH -lHB'' For examples, one can look in the makefile in ''test''. ==Making your own exclusion routines== To make your own exclusion routine, it is good to start with ''dsacbnd9.f'' in ''darksusy-x.y.z/src/ac'' . Copy this into your run directory, and change the name to, for example ''dsacbndX.f '' where ''X''' should not be 0-9, since these are in use. (Probably best to avoid a number altogether) Make sure to change the name on the first line in the file as well. Now you may call: ''call dsacbndX'' in your DarkSusy code as ''dsmain'' demonstrates. ''gfortran -I$PWD/../include -L$PWD/../lib -o ProgramName ProgramName.f dsacbndX.f -ldarksusy -lFH -lHB'' [[Category:Installing]] da4d1049360510f1164bfd53f37beca9636e2c05 0 234 1782 1727 2012-03-15T16:07:18Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] b048b79bafa7dd8442d053d9604bb2ce6f960882 1783 1782 2012-03-15T16:07:53Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] 6b7b72422a76fb9352bf4af0244b2934e7817073 6 407 1784 2012-03-15T16:09:15Z Nfyal 26 PhD Thesis of Arshak Tonoyan presenting the first in the LHC history measurement of the top quark charge. wikitext text/x-wiki PhD Thesis of Arshak Tonoyan presenting the first in the LHC history measurement of the top quark charge. d5e29946745ab6722bad91ea377c7d0c1e79f3b3 0 405 1785 1764 2012-04-10T09:10:00Z Kmo078 65 wikitext text/x-wiki Astroparticle ----------------------- * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: 9abb8da29949649845a8665366ba02d592ce8ef8 1787 1785 2012-04-10T09:13:22Z Kmo078 65 wikitext text/x-wiki Astroparticle ----------------------- * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] 552283f0fab56bc5f1c628c3d1d83435461b2a88 1788 1787 2012-04-10T09:13:47Z Kmo078 65 wikitext text/x-wiki Astroparticle ----------------------- * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[RapportOlgaMaster.pdf]] f9228eac19070deeea70b3fdae92c187f29b2358 1789 1788 2012-04-10T09:13:57Z Kmo078 65 wikitext text/x-wiki Astroparticle ----------------------- * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] 552283f0fab56bc5f1c628c3d1d83435461b2a88 1796 1789 2012-04-19T10:47:33Z Hsa061 18 wikitext text/x-wiki Astroparticle ----------------------- * Servant: http://arxiv.org/abs/1204.2797 * Weinger: http://arxiv.org/abs/1204.2797 * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] a19e401ae2a8b1d58959855eba76791aa7484a4d 1797 1796 2012-04-19T10:48:13Z Hsa061 18 wikitext text/x-wiki Astroparticle ----------------------- * Weinger: http://arxiv.org/abs/1204.2797 * Servant: http://arxiv.org/abs/0912.0004 * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] 52c864adb956126c03399aaff36eaec1d4b59927 1810 1797 2012-07-31T09:00:06Z Hsa061 18 wikitext text/x-wiki Astroparticle ----------------------- * Fermi-Lat: http://arxiv.org/abs/1205.2739 * Weinger: http://arxiv.org/abs/1204.2797 * Servant: http://arxiv.org/abs/0912.0004 * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] a0a3a8a3d88f47c8ce1ad38c47a653b158989063 1811 1810 2012-07-31T09:03:17Z Hsa061 18 wikitext text/x-wiki Astroparticle ----------------------- * Fermi-Lat: http://arxiv.org/abs/1205.2739 * Weniger: http://arxiv.org/abs/1204.2797 * Servant: http://arxiv.org/abs/0912.0004 * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] d49e523e406e2a86f7af4570ab7062d2e75fe09f 1815 1811 2012-08-31T09:01:10Z St01355 57 wikitext text/x-wiki Astroparticle ----------------------- * Investigating Gamma-Ray Lines from Dark Matter with Future Observatories: http://arxiv.org/abs/1207.6773 * Fermi-Lat: http://arxiv.org/abs/1205.2739 * Weniger: http://arxiv.org/abs/1204.2797 * Servant: http://arxiv.org/abs/0912.0004 * Profuma: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] 414f9251556f661a4b3c782c7ff3a7730fe66d51 6 408 1786 2012-04-10T09:12:39Z Kmo078 65 Master's Thesis by Olga Bessidskaia at Stockholm University 2012 wikitext text/x-wiki Master's Thesis by Olga Bessidskaia at Stockholm University 2012 4a6184d2fe9ff61e30804c1bbd2f369a2c256023 0 203 1790 1438 2012-04-16T09:29:56Z Dfe002 7 /* How to get to CERN */ updated bus/tram wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23 or 57 to Blandonnet, and then change to the tram 14 "CERN". There is also a CERN shuttle bus to/from the airport ([https://espace.cern.ch/info-RegularShuttleService/default.aspx timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 0305d7e011a436ca840cee564edd306115ed40cd 1791 1790 2012-04-16T09:34:49Z Dfe002 7 /* How to get to CERN */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23 or 57 to Blandonnet, and then change to the tram 14 "CERN". Check [www.tpg.ch tpg.ch] for the timetable. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 313f992b636b85cc93fa346e7b722ed61c63ac9e 1792 1791 2012-04-16T09:35:06Z Dfe002 7 /* How to get to CERN */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23 or 57 to Blandonnet, and then change to the tram 14 "CERN". Check [http://www.tpg.ch tpg.ch] for the timetable. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 4a51544fc924b953a9b8f3ddcecbb9b981af8f30 6 409 1793 2012-04-18T14:16:13Z Kmo078 65 Presentation given in Stockholm by Knut Dundas Morå wikitext text/x-wiki Presentation given in Stockholm by Knut Dundas Morå 90faa4bfe180963af65c7eef9d09c05c0822f2d3 0 348 1794 1698 2012-04-18T14:19:42Z Kmo078 65 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes * ''Thesis plans, Stockholm meeting'' [File:Stockholmpresentation120323.pdf] (12.mars 2012), Knut Morå == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844 ATL-COM-PHYS-2011-1619] (25. november 2011) == Theses == === Master === === PhD === 50149baeada7e61c40cff63b69228ff31f2175fa 1795 1794 2012-04-18T14:20:05Z Kmo078 65 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes * Thesis plans, Stockholm meeting [File:Stockholmpresentation120323.pdf] (12.mars 2012), Knut Morå == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844 ATL-COM-PHYS-2011-1619] (25. november 2011) == Theses == === Master === === PhD === 9b7daada40f9af1d418b813982022b2c68c454a5 1809 1795 2012-06-29T10:24:12Z Kmo078 65 La til min presentasjon ved Katten siden Twiki-oppdateringer ble oppfordret. wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes * "Higgs-Mekanismen", presentasjon for Bergen Katedralskole (19.12.2011) Knut Morå == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes * Thesis plans, Stockholm meeting [File:Stockholmpresentation120323.pdf] (12.mars 2012), Knut Morå == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844 ATL-COM-PHYS-2011-1619] (25. november 2011) == Theses == === Master === === PhD === ae8f5e1acfa6f65793fe71b5864ee74508fefa24 0 28 1798 1679 2012-04-23T08:39:58Z Nfyku 4 Oppdatert til icflow_2008.2o wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. ssh -X mikroserver2 /prog/design_kits/micro.init.csh ==Starte opp IC studio== Skriv i et terminalvindu: # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 tcsh source /prog/design_kits/mentor_init/mentor-s35d4.csh unsetenv LANG ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. Om du ønsker å bruke Mentor programmene fra en Windows-PC så se på forklaringene i [[Teknisk hjelp]] ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: /prog/mentor/icflow_2008.2o/2008.2o_rhelx86linux/icflow_home/shared/htmldocs start f.eks. firefox slik: firefox file:/prog/mentor/icflow_2008.2o/2008.2o_rhelx86linux/icflow_home/bin/icstudio/_bk_icda.html Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: acroread /prog/mentor/icflow_2008.2o/2008.2o_rhelx86linux/icflow_home/shared/pdfdocs/daic_user.pdf ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". [[Category:Mikroelektronikk]] 84eef36e4f1aff5a4b860e49e05ecc2352c75bcf 1799 1798 2012-04-23T09:05:21Z Nfyku 4 wikitext text/x-wiki = Kom igang med IC studio = Dette er en kort beskrivelse av hvordan man bruker IC studio for å tegne kretsskjema, lage nettliste og kjøre simulering. Første gang man skal arbeide med Mentor Graphics verktøy skriv følgende kommando og start deretter et nytt skall. Dette skal du kun gjøre en gang for din konto. ssh -X mikroserver2 /prog/design_kits/micro.init.csh ==Starte opp IC studio== Skriv i et terminalvindu: # Slå av autorepeat for funksjonstaster xset -r 67 -r 68 -r 69 -r 70 -r 71 -r 72 -r 73 -r 74 -r 75 -r 76 -r 95 -r 96 ssh -X mikroserver2 tcsh source /prog/design_kits/mentor_init/mentor-s35d4.csh unsetenv LANG ams_icstudio -project mgc/mitt_prosjekt -tech c35b4c3 & Du kan endre mitt_prosjekt til det du selv ønsker, men uten mellomrom. Kommandoen starter IC studio med AMS-biblioteket til prosessen c35b4c3. Om du ønsker å bruke Mentor programmene fra en Windows-PC så se på forklaringene i [[Teknisk hjelp]] ==Dokumentasjon== Trenger du hjelp til skjemategning og/eller Design Architect generelt, kan du finne dokumentasjon her: $MGC_HOME/shared/htmldocs start f.eks. firefox slik: firefox file:///$MGC_HOME/shared/infohubs/common/html/index.html\?infohub=icstudio_ih\&tab=docs Det finnes også pdf-utgaver av dokumentasjonen. Den kan leses slik: acroread $MGC_HOME/shared/pdfdocs/daic_user.pdf ==Åpne et nytt skjema== Høyre-klikk Library-vinduet. Velg "New Library" og fyll inn f.eks. "My designs". Klikk på det nye biblioteket og høyre-klikk deretter i Cell-vinduet og velg "New View". Sett "View Type" til Schematic, slik som vist i figuren. Gi det nye skjemaet et navn. Deretter trykker du Finish. Du skal nå få opp Design-Architect-IC. [[Image:IC_studio_new_view.png|800px]] velg "Show/Hide Library Palette" fra ikonlisten til venstre, nr 2 fra bunnen. Trykk på "HIT-Kit Utilities" Velg symboler fra AMS-biblioteket eller fra standard-biblioteket. AMS-biblioteket inneholder komponenter som er mulig å lage i c35b4-prosessen. Standard-biblioteket inneholder standard-komponenter og ideelle komponenter. Fra menyen til høyre: Velg AMS Library eller Library. I Design Architect-IC kalles skjemasymbol for "instance". Symboler for spenningsnett (GND og VDD) finnes ved å velge: AMS Library - etc - cell power. Det er enklest å bruke ideelle motstander og kondensatorer hvis du bare skal gjøre en simulering. Hvis du bruker slike komponenter må du legge til en "property" som kalles "INSTPAR" med den verdien motstanden eller kondensatoren skal ha, for eksempel 1k eller 1p. Dette gjøres ved å høyre-klikke på komponenten, velge properties->add og skrive inn INSTPAR på property name og verdien på komponenten under property value. For å tegne ledninger: Velg Add &#150; Wire fra menyen til høyre, eller trykk F3 på tastaturet. En ledning avsluttes ved å trykke Enter. Trykk Esc for å avslutte add wire mode. Sett navn på nettene (forbindelsene) som inn, ut, GND. Velg: Name &#150; Net fra menyen til høyre. Net med samme navn blir koblet i sammen selv om det ikke er kabel mellom de. Kilder (spenning-, strøm- og signalkilder) finnes under Add->Source i fil-menyen på toppen. Gjør innstillinger i dialogboksen, trykk OK og plasser symbolet på skjemaet. For GBW målinger bruker du en AC kilde med magnitude på 1. For å se signalet i et tids spekter kan du velge en sinusspenning med frekvens på f. eks. 1000Hz og amplitude 1V. Transistorene finnes under "Ams-Library &#8594; Devices &#8594; MOS", bruk nmos4 for nmos og pmos4 for pmos Skjemaet lagres ved å trykke Check & Save fra menyen til høyre. ==Design Viewpoint== Før vi kan begynne med simulering må vi sette &#147;design viewpoint&#148;. Velg <s>AMS DVE </s> "AMS Utilities &#8594; create viewpoint"fra menyen til høyre eventuellt "Hit-Kit Utilities &#8594; create viewpoint" fra fil-menyen på toppen. Skriv inn stien til prosjektkatalogen (samme som cell name i ICstudio, dvs $navn_på_library/default.group/logic.views/navn_på_cell) og kontroller at de andre innstillingene stemmer, dvs C35B4 og Device skal være nedsunket. Når du har trykket OK genereres en ny underkatalog som inneholder info om den prosessen vi skal bruke. I denne katalogen vil du etterhvert også finne nettlisten (en tekstfil som beskriver kretsen). Dette trenger du bare gjøre én gang, men du kan ikke gjøre det før etter du har trykket Check & Save første gang. ==Simulering== Når vi skal simulere må vi gå inn i &#147;simuleringsmodus&#148;. Velg Simulation fra menyen til høyre. Siden vi bare har ett viewpoint i prosjektet vårt skal dette være valgt i Config Name (øverst). Velg OK. Så er vi i simuleringsmodus. Vi må fortelle netlisteren hvilket nett som er 0-referanse (jord/GND). Velg Session &#150; Netlister fra menyen til høyre. Skriv inn under Set Node 0 navnet du satte på jord-nettet i skjemaet. Trykk OK. Vi må velge prosesshjørne. Det finnes under menyen oppe: HIT KIT Utilities / Set simulation models. Her trenger du ikke endre på noe, men du må ha vært innom her og trykket OK for å bekrefte &#147;typical&#148;. Setup &#8594; Forces definerer nettverk verdiene (f. eks. input og vdd). ==Analyser, prober og plot== Vi må sette prober og analyser for å få noe fornuftig ut av simulatoren. Velg f. eks. inngangen og utgangen på kretsen ved å klikke på skjemaet mens du holder nede control. Velg Wave Outputs fra menyen til høyre. Under object velger du en eller flere av nettene du har valgt, under analysis velger du analyse metoden og under modifier velger du hvilke signal du vil se. Du kan velge flere typer ved å holde nede control. Tilslutt trykker du på knappen med tegningen av et ark med et pluss tegn på. Velg Analyses (igjen fra menyen til høyre) og merk av f. eks. Transient om du har en sinus kilde, AC om du har en AC kilde. Hak og av for DCOP for å få DC operating point data. Trykk Setup-knappen ved siden av Transient og sett f. eks. som vist på figuren under. [[File:transient.png|400px]] Dersom du vil kjøre en noise analyse så må du ha en AC kilde og du må hake av for AC og NOISE analyse, i setupen til noise analysen velger du navnet på AC kilden under "Input noise source" og navnet på nettet til utgangen din under "Output noise net". Under "Print frequency point every" skriver du antall ganger på en dekade programmet skal regne ut støyen, dersom du vil finne ut total output/input noise må dette tallet være over 0. Hak så av for de plottene du vil ha. Total output/input noise pluss støyen ved hver dekade fra 1-50Mhz blir skrevet til .chi filen. Plottene er gitt i V/rot(Hz) Nå er det bare å generere nettliste og kjøre simulering. Simulatoren vi bruker heter ELDO. Hvis vi kun vil generere nettliste bruker vi knappen Netlist. Ved å trykke på knappen Run ELDO genereres nettlisten og simulatoren kjøres. ELDO kjøres i bakgrunnen og skriver statusmeldinger til log-vinduet under skjemaet. Sjekk at du ikke får feilmeldinger før du prøver å analysere resultatene. Dersom du satte på DCOP under analyse vil du finne alle nodespenningene og total power consumption for kretsen i loggen.Denne informasjonen kan du og finne igjen i .chi-filen. For å studere resultat-plottene, velg View Waves fra menyen til høyre. Dette starter programmet EZwave, som brukes til å studere simuleringsresultater. For å plotte en eller flere signaler så velger du signalet i treet på venstre side, høyre-klikker og velger plot-stacked for å få de under hverandre eller plot-overlayed for å få de oppå hverandre. Du kan så legge til en cursor ved å tryke på ikonet som ar to bokser med et pluss tegn i mellom, eller ved å bruke F5. Cursoren kan nå flyttes frem og tilbake manuelt, eller du kan høyreklikke og velge "Move To..." og taste inn hvor du vil den skal flyttes. For å gjøre kalkulasjoner på signalet kan du trykk på knappen med tegning av en blyant og to linjaler, eller du kan trykke Ctrl-M. Du velger først signalet du vil måle på ved å trykke på navnet ved siden av grafen for så å trykke på knappen inni measurement tool som er ved siden av den med viskelær. Har du f.eks et sinus signal så kan du måle peak to peak ved å hake av for det, velge "Apply measurement to" "visible X region only" dersom du har zoomet inn, eller "entire waveform" ellers. Er det pulstog eller lignende du simulerer så kan du velge timedomain under measurement øverst og du vil få en oppdatert meny ved siden av som har mange relevante målemetoder. Når du vil gjøre forandringer i skjemaet velger du End Sim, og du er tilbake i &#147;skjema-modus&#148;. Når du igjen skal simulere: Velg Check & Save. Velg Simulation for å gå inn i simuleringsmodus. Velg Run ELDO for å kjøre simulering med samme innstillinger som sist. Du kan endre parametre direkte ved å holde musen over parameteren og trykke shift-F7. Dersom du endrer på noen parametre inne i simuleringsmodus slikat teksten blir rød så kan du fjerne endringen med shift-F6. Treffer du en komponent og den blir fjernet så gjør undo ved å trykke U. ==Eldo og dens filer== Nettlisten består av én eller flere filer. Hovedfilen finnes i katalogen *vpt_s35d4_device* og har navnet *.cir. Denne er en tekstfil som kan leses av mennesker (i f.eks. en tekst-editor). Filen inneholder informasjon om hvor bibliotekene ligger og hvilke plot vi vil ha ut. DA Lager hovedfilen enkel, og bruker denne til å inkludere de andre filene. Det er en god idé å åpne disse filene og studere dem. Spør noen som vet. Hvis vi har en enkel krets kan vi skrive .cir-filen på egenhånd uten å tegne skjema i DA. Simulatoren kan vi selv kjøre fra kommandolinje i et terminalvindu med kommandoen: <pre> eldo filnavn.cir </pre> hvor &#147;filnavn.cir&#148; er kildefilen. ELDO produserer forskjellige output-filer: - .chi-filen er en tekstfil hvor ELDO lister opp alt den har gjort. Her finnes kildekoden, info om feil og advarsler, data for hvordan transistorene oppfører seg (metning/lineært område) hvor lang tid simuleringen tok og mere til. Letteste måten å finne ut hvor .chi filen blir av er å studere message area nederst etter at du har fullført en eldo simulering. Om ikke vinduet er der så trykk på setup knappen på ikonmenyen øverst, den helt til venstre, og hak av for "Show message area" og trykk ok. Etter simuleringen får du opp <pre> Note : Now processing: /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.op1 </pre> I fra shellet kan du åpne .chi filen ved å kopiere pathen fra over, men skifte ut op1 på slutten med chi, feks slik: <pre> less /heim/brukernavn/mgc/mitt_prosjekt.proj/navn_på_library.lib/default.group/logic.views/navn_på_cell/vpt_c35b4_device/navn_på_cell_vpt_c35b4_device.chi </pre> når filen er åpnet kan du trykke shift-g så kommer du til slutten av filen, ruller du tre sider opp sånn ca så er du ved transistor dataen. Du kan og bruke gedit istedet for less, da får du det opp i "notepad". Her står det om transistorene er i metning eller ikke og alle andre parametre, ignorer det negative tegnet på kondensatorene, ro er det samme som 1/GDS. - .attr er en fil med de plottene vi spurte etter. Denne må åpnes i Xelga eller DA IC View. ==Tips== For å gjøre det lettere å bruke programmet kan vi sette noen innstillinger i DA-vinduet. Velg MGC &#150; Setup &#150; Session. Velg f. eks. disse innstillingene: Måten DA bruker for å velge symboler med kan virke litt rar. Det kan du stille på ved å velge Session i menyen til høyre (ikke ha schematic-vinduet aktivt). Fra rullegardinmenyene velg: Setup &#150; Selection. Bytt gjerne fra Additive til Individual. Dersom du ikke har et grått meldingsvindu nederst, er det en fordel å hake av for dette inni setup. Vinduet gir meldinger som ikke dukker opp i library vinduet. For at DA skal huske disse innstillingene til neste gang velger du fra rullegardinmenyene: Setup - Save Setup. Hvis du får en feilmelding (nederst på skjermen) som sier &#147;katalogen /mgc/startup finnes ikke&#148;, så er det bare å opprette en slik katalog og prøve igjen. = Tutorial for konstruksjon av inverter og symbol = Tutorialet forutsetter at du har gjort det som står under [[IC_studio#Starte_opp_IC_studio]] og fått startet programmet. 1. Om du ikke allerede har et library så kan du høyre-klikke i Library ruten og velge "New Library". Kall bibloteket noe fornuftig. 2. Høyre-klikk i Cell vinduet og velg "New Cell View". Kall cellen for inverter, velg schematic under "View Type". Trykk Finish og Design Architect vil åpne seg. 3. Om det ikke er en meny på høyre side så trykker du på "Toggle lib" knappen på venstre meny, nest nederst. 4. Trykk på "HIT-Kit Utilities" på den høyre menyen. 5. Legg til nmos transistoren som under ved å gå til "Devices->MOS->nmos4", når vinduet kommer opp trenger du ikke endre noe siden n-transistoren skal ha unity size. W er satt til 0.4, men har en effektiv lengde på 0.35 i produksjonen. 6. Legg til nmos transistoren som under ved å gå til "Devices->MOS->pmos4", når vinduet kommer opp trykker du på "Change WTOT" og fyller inn 1. I følge databladet har Kp en gjennomsnittsverdi på 170uA/v og Kn har 58uA/V. Så det må være en faktor på 3 mellom n og p transistorene. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til port inn og port ut. De ligger under "etc->portin" og "etc->portout". 9. Legg til kabler som vist under. Du starter kablingen ved å trykke W, klikk en gang for å begynne en kabel, en gang til et annet sted for å henge den fast der og to ganger et sted for å stoppe kabelen. Du slutter kabel trekkingsverktøyet med ESC. 10. Skift navn på nettet til portene ved å først trykke på kabelen fremfor porten slik at den blir hvit for så å trykke på "Net name" knappen på menyen til venstre. Kall innporten for A og utporten for Q. 11. Trykk på "File->Check schematic" om det er listet noen errors så fiks disse, warnings er vanligvis ikke så nøye. [[File:inverter.jpg|400px]] 12. Trykk på "Miscellaneous->Generate symbol". I vinduet som dukker opp trykker du på "Choose shape" og velger "Buffer". Trykk OKx2 og du får opp symbolet til kretsen din. 13. Trykk på kabelen under "out" merket og trykk delete. 14. Trykk på Circle knappen på høyre side og lag en sirkel foran spissen på bufferet. 15. Trykk på Polyline knappen på høyre side og trekk en strek fra pinnen til sirkelen som vist under. 16. Trykk på "Setup->Select filter" på fil menyen. Hak av for allt og trykk ok. 17. Trykk så på "hide labels" på venstre side. [[File:symbol.jpg|200px]] 13. Trykk "Check & Save" på venstre side og gå tilbake til library vinduet. Har du lagt symbolet inn i et nytt skjema, men har sener oppdatert eller endret noe i symbolet eller den bakomliggende kretsen så må du høyreklikke på symbolet i skjemaet og velge "Update". [[Category:Mikroelektronikk]] 0c7157bff924bc96b96ce8b32b74c491c77deff5 0 3 1800 1627 2012-04-23T11:43:03Z Nfyku 4 Added version 58 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 8910110335cdd7bcb78ab80e0884ff18357e2abe 0 242 1801 1610 2012-04-23T13:20:43Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L1 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L1A trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L1 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[0] |Serial B channel on/off Default: 1 |---- |RW |[1] |Disable_error_masking 0 |---- |RW |[2] |NA 0 |---- |RW |[3] |L0 support 1 |---- |RW |[4:7] |Not Used |---- |RW |[8] |L2a FIFO storage mask 1 |---- |RW |[9] |L2r FIFO storage mask 1 |---- |RW |[10] |L2 Timeout FIFO storage mask 1 |---- |RW |[11] |L1a message mask 1 |---- |RW |[12] |Trigger Input Mask Enable 0 |---- |RW |[13:15] |Not Used |---- |RW |[16] |Bunch_counter overflow |---- |RW |[17] |Run Active - |---- |RW |[18] |Busy (receiving sequence) - |---- |RW |[19] |Not Used |---- |RW |[23:20] |CDH version 0x2 |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3014 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3015 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3050 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3052 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3053 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 9d21686a78364ef506e5242f52b6278e0ac3c72d 1802 1801 2012-04-24T06:44:06Z Nfyku 4 Updated Trigger Modules Regesiter definition wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L1 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L1A trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L1 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Type !Description |---- | <nowiki>Control[23:0]</nowiki> | 0x3000 | RW | <nowiki>[0] Serial B channel on/off </nowiki> ''Default: ''1'' <nowiki>[1] </nowiki> Disable_error_masking ''0'' <nowiki>[2] NA</nowiki> ''0'' <nowiki>[3] L0 support </nowiki> ''1'' <nowiki>[4:7] </nowiki> ''(Not Used)'' <nowiki>[8] L2a FIFO storage mask</nowiki> ''1'' <nowiki>[9] L2r FIFO storage mask</nowiki> ''1'' <nowiki>[10] L2 Timeout FIFO storage mask</nowiki> ''1'' <nowiki>[11] L1a message mask </nowiki> ''1'' <nowiki>[12]</nowiki> '' ''Trigger Input Mask Enable ''0'' <nowiki>[13:15] </nowiki> ''(Not Used)'' <nowiki>[16] </nowiki> Bunch_counter overflow - <nowiki>[17] Run Active </nowiki> - <nowiki>[18] Busy (receiving sequence)</nowiki> - <nowiki>[19] </nowiki> ''Not Used'' <nowiki>[23:20] CDH version </nowiki> 0x2 |- | Module Reset | 0x3001 | T | Reset Module |- | NA | 0x3002 | | |- | NA | 0x3003 | | |- | Reset Counters | 0x3004 | T | Write to this registers will reset the counters in the module |- | Issue Testmode | 0x3005 | T | Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |- | <nowiki>L1_Latency[15:0]</nowiki> | 0x3006 | RW | <nowiki>[15:12] Uncertainty region +- N. default value 0x2 (50 ns)</nowiki> <nowiki>[11:0] Latency from L0 to L1, default value 0x0D4 (5.3 us) </nowiki> |- | <nowiki>L2_Latency[31:0]</nowiki> | 0x3007 | RW | <nowiki>[15:0] Max Latency from BC0 to L2, default value 0x4E20 (500 us)</nowiki> <nowiki>[31:16] Min Latency from BC0 to L2, default value 0x0C80 (80 us)</nowiki> |- | L2_Extdended <nowiki>Latency[31:0]</nowiki> | 0x3009 | RW | <nowiki>[15:0] Max Latency from BC0 to L2 Extended window end, default value 0x4E48 (501 us)</nowiki> <nowiki>[31:16] Min Latency from BC0 to L2 Extended window start, default value 0x0C80 (80 us)</nowiki> |- | <nowiki>L1_msg_latency[31:0]</nowiki> | 0x300A | RW | <nowiki>[15:0] Max Latency from BC0 to L1 </nowiki> msg, default value 0x0028 (1 us) <nowiki>[31:16] Min Latency from BC0 to L1 </nowiki> msg, default value 0x0F8 (6,2 us) |- | Pre_pulse_counter <nowiki>[15:0]</nowiki> | 0x300B | R | Number of decoded pre-pulses. |- | BCID_Local <nowiki>[11:0]</nowiki> | 0x300C | R | Number of bunchcrossings at arrival of L1 trigger. |- | <nowiki>L0_counter[15:0]</nowiki> | 0x300D | R | Number of L0 triggers |- | <nowiki>L1_counter[15:0]</nowiki> | 0x300E | R | Number of L1 triggers |- | <nowiki>L1_msg_counter[15:0]</nowiki> | 0x300F | R | Number of successfully decoded L1 messages |- | <nowiki>L2a_counter[15:0]</nowiki> | 0x3010 | R | Number of successfully decoded L2a messages |- | <nowiki>L2r_counter[15:0]</nowiki> | 0x3011 | R | Number of successfully decoded L2r messages |- | NA | 0x3012 | | |- | Bunchcounter <nowiki>[11:0]</nowiki> | 0x3013 | R | Debug: Number of bunchcrossings |- | hammingErrorCnt <nowiki>[31:0]</nowiki> | 0x3016 | R | <nowiki>[15:0] Number of single bit hamming errors [31:16] Number of double bit hamming errors</nowiki> |- | ErrorCnt <nowiki>[31:0]</nowiki> | 0x3017 | R | <nowiki>[15:0] Number of message decoding errors </nowiki> <nowiki>[31:16] Number of errors related to sequence and timeouts.</nowiki> |- | Buffered_events <nowiki>[4:0]</nowiki> | 0x3020 | R | Number of events stored in the FIFO. |- | <nowiki>DAQ_Header01[31:0]</nowiki> | 0x3021 | R | Latest received DAQ Header 1 |- | <nowiki>DAQ_Header02[31:0]</nowiki> | 0x3022 | R | Latest received DAQ Header 2 |- | <nowiki>DAQ_Header03[31:0]</nowiki> | 0x3023 | R | Latest received DAQ Header 3 |- | <nowiki>DAQ_Header04[31:0]</nowiki> | 0x3024 | R | Latest received DAQ Header 4 |- | <nowiki>DAQ_Header05[31:0]</nowiki> | 0x3025 | R | Latest received DAQ Header 5 |- | <nowiki>DAQ_Header06[31:0]</nowiki> | 0x3026 | R | Latest received DAQ Header 6 |- | <nowiki>DAQ_Header07[31:0]</nowiki> | 0x3027 | R | Latest received DAQ Header 7 |- | Event_info <nowiki>[17:0]</nowiki> | 0x3028 | R | Latest Received Event information: <nowiki>[0] ‘0’</nowiki> <nowiki>[1] Region of Interest announced (=ESR)</nowiki> <nowiki>[2] ‘0’</nowiki> <nowiki>[3] ‘0’</nowiki> <nowiki>[4:7] Calibration/SW trigger type (= </nowiki> RoC) <nowiki>[8] Software trigger event</nowiki> <nowiki>[9] Calibration trigger event</nowiki> <nowiki>[10] Event has L2 Reject trigger</nowiki> <nowiki>[11] Event has L2 Accept trigger</nowiki> <nowiki>[12] Include payload</nowiki> <nowiki>[17:13] SCLK phase when (L0/L1)trigger arrives</nowiki> |- | Event_error <nowiki>[24:0]</nowiki> | 0x3029 | R | Latest Received Event error conditions: <nowiki>[0] Serial B Stop Bit Error</nowiki> <nowiki>[1] Single Bit Hamming Error Individually </nowiki> Addr. <nowiki>[2] Double Bit Hamming Error Individually </nowiki> Addr. <nowiki>[3] Single Bit Hamming Error Broadcast.</nowiki> <nowiki>[4] Double Bit Hamming Error Broadcast.</nowiki> <nowiki>[5] Unknown Message Address Received</nowiki> <nowiki>[6] Incomplete L1 Message</nowiki> <nowiki>[7] Incomplete L2a Message</nowiki> <nowiki>[8] NA </nowiki> <nowiki>[9] </nowiki> TTCrx Address Error (not X”0003”) <nowiki>[10] Spurious L0 </nowiki> <nowiki>[11] Missing </nowiki> L0 <nowiki>[12] Spurious L1</nowiki> <nowiki>[13] Boundary L1</nowiki> <nowiki>[14] Missing L1</nowiki> <nowiki>[15] L1 message arrives outside legal timeslot</nowiki> <nowiki>[16] L1 message missing/timeout</nowiki> <nowiki>[17] L2 message arrives outside legal timeslot</nowiki> <nowiki>[18] L2 message missing/timeout</nowiki> <nowiki>[19] Boundary L2 Message</nowiki> <nowiki>[20] NA</nowiki> <nowiki>[21] </nowiki> Prepulse error (=0; possible future use) <nowiki>[22] L1 message content error</nowiki> <nowiki>[23] L2 message content error</nowiki> <nowiki>[24] NA</nowiki> |- | <nowiki>L1_MessageHeader[11:0]</nowiki> | 0x3030 | R | Debug: Latest received L1 Message |- | <nowiki>L1_MessageData1[11:0]</nowiki> | 0x3031 | R | Debug: Latest received L1 Message |- | <nowiki>L1_MessageData2[11:0]</nowiki> | 0x3032 | R | Debug: Latest received L1 Message |- | <nowiki>L1_MessageData3[11:0]</nowiki> | 0x3033 | R | Debug: Latest received L1 Message |- | <nowiki>L1_MessageData4[11:0]</nowiki> | 0x3034 | R | Debug: Latest received L1 Message |- | <nowiki>L2aMessageHeader[11:0]</nowiki> | 0x3035 | R | Debug: Latest received L2a Message |- | <nowiki>L2aMessageData1[11:0]</nowiki> | 0x3036 | R | Debug: Latest received L2a Message |- | <nowiki>L2aMessageData2[11:0]</nowiki> | 0x3037 | R | Debug: Latest received L2a Message |- | <nowiki>L2aMessageData3[11:0]</nowiki> | 0x3038 | R | Debug: Latest received L2a Message |- | <nowiki>L2aMessageData4[11:0]</nowiki> | 0x3039 | R | Debug: Latest received L2a Message |- | <nowiki>L2aMessageData5[11:0]</nowiki> | 0x303A | R | Debug: Latest received L2a Message |- | <nowiki>L2aMessageData6[11:0]</nowiki> | 0x303B | R | Debug: Latest received L2a Message |- | <nowiki>L2aMessageData7[11:0]</nowiki> | 0x303C | R | Debug: Latest received L2a Message |- | <nowiki>L2rMessageHeader[11:0]</nowiki> | 0x303D | R | Debug: Latest received L2r Message |- | RoIMessageHeader <nowiki>[11:0]</nowiki> | 0x303E | R | Debug: Latest received RoI Message |- | <nowiki>RoIMessageData1[11:0]</nowiki> | 0x303F | R | Debug: Latest received RoI Message |- | <nowiki>RoIMessageData2[11:0]</nowiki> | 0x3040 | R | Debug: Latest received RoI Message |- | <nowiki>RoIMessageData3[11:0]</nowiki> | 0x3041 | R | Debug: Latest received RoI Message |- | FIFO_read_enable | 0x3080 | T | Debug: Triggers a readout pulse to FIFO |- | FIFO_DAQHeader <nowiki>[31:0]</nowiki> | 0x3081 | R | Debug: Output of FIFO |} 6ad9b90ce83799f27ecc8527261548ab74d02826 1803 1802 2012-04-24T07:15:18Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L1 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L1A trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L1 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Type !Description |---- | Control[23:0] | 0x3000 | RW | * [0] Serial B channel on/off ''Default: ''1'' * [1] Disable_error_masking ''0'' * [2] NA ''0'' * [3] L0 support ''1'' * [4:7] ''(Not Used)'' * [8] L2a FIFO storage mask ''1'' * [9] L2r FIFO storage mask ''1'' * [10] L2 Timeout FIFO storage mask ''1'' * [11] L1a message mask ''1'' * [12] '' ''Trigger Input Mask Enable ''0'' * [13:15] ''(Not Used)'' * [16] Bunch_counter overflow - * [17] Run Active - * [18] Busy (receiving sequence) - * [19] ''Not Used'' * [23:20] CDH version 0x2 |- | Module Reset | 0x3001 | T | Reset Module |- | NA | 0x3002 | | |- | NA | 0x3003 | | |- | Reset Counters | 0x3004 | T | Write to this registers will reset the counters in the module |- | Issue Testmode | 0x3005 | T | Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |- | L1_Latency[15:0] | 0x3006 | RW | * [15:12] Uncertainty region +- N. default value 0x2 (50 ns) * [11:0] Latency from L0 to L1, default value 0x0D4 (5.3 us) |- | L2_Latency[31:0] | 0x3007 | RW | * [15:0] Max Latency from BC0 to L2, default value 0x4E20 (500 us) * [31:16] Min Latency from BC0 to L2, default value 0x0C80 (80 us) |- | L2_Extdended Latency[31:0] | 0x3009 | RW | * [15:0] Max Latency from BC0 to L2 Extended window end, default value 0x4E48 (501 us) * [31:16] Min Latency from BC0 to L2 Extended window start, default value 0x0C80 (80 us) |- | L1_msg_latency[31:0] | 0x300A | RW | * [15:0] Max Latency from BC0 to L1 msg, default value 0x0028 (1 us) * [31:16] Min Latency from BC0 to L1 msg, default value 0x0F8 (6,2 us) |- | Pre_pulse_counter[15:0] | 0x300B | R | Number of decoded pre-pulses. |- | BCID_Local[11:0] | 0x300C | R | Number of bunchcrossings at arrival of L1 trigger. |- | L0_counter[15:0] | 0x300D | R | Number of L0 triggers |- | L1_counter[15:0] | 0x300E | R | Number of L1 triggers |- | L1_msg_counter[15:0] | 0x300F | R | Number of successfully decoded L1 messages |- | L2a_counter[15:0] | 0x3010 | R | Number of successfully decoded L2a messages |- | L2r_counter[15:0] | 0x3011 | R | Number of successfully decoded L2r messages |- | NA | 0x3012 | | |- | Bunchcounter[11:0] | 0x3013 | R | Debug: Number of bunchcrossings |- | hammingErrorCnt[31:0] | 0x3016 | R | [15:0] Number of single bit hamming errors [31:16] Number of double bit hamming errors |- | ErrorCnt[31:0] | 0x3017 | R | * [15:0] Number of message decoding errors * [31:16] Number of errors related to sequence and timeouts. |- | Buffered_events[4:0] | 0x3020 | R | Number of events stored in the FIFO. |- | DAQ_Header01[31:0] | 0x3021 | R | Latest received DAQ Header 1 |- | DAQ_Header02[31:0] | 0x3022 | R | Latest received DAQ Header 2 |- | DAQ_Header03[31:0] | 0x3023 | R | Latest received DAQ Header 3 |- | DAQ_Header04[31:0] | 0x3024 | R | Latest received DAQ Header 4 |- | DAQ_Header05[31:0] | 0x3025 | R | Latest received DAQ Header 5 |- | DAQ_Header06[31:0] | 0x3026 | R | Latest received DAQ Header 6 |- | DAQ_Header07[31:0] | 0x3027 | R | Latest received DAQ Header 7 |- | Event_info[17:0] | 0x3028 | R | Latest Received Event information: * [0] ‘0’ * [1] Region of Interest announced (=ESR) * [2] ‘0’ * [3] ‘0’ * [4:7] Calibration/SW trigger type (= RoC) * [8] Software trigger event * [9] Calibration trigger event * [10] Event has L2 Reject trigger * [11] Event has L2 Accept trigger * [12] Include payload * [17:13] SCLK phase when (L0/L1)trigger arrives |- | Event_error[24:0] | 0x3029 | R | Latest Received Event error conditions: * [0] Serial B Stop Bit Error * [1] Single Bit Hamming Error Individually Addr. * [2] Double Bit Hamming Error Individually Addr. * [3] Single Bit Hamming Error Broadcast. * [4] Double Bit Hamming Error Broadcast. * [5] Unknown Message Address Received * [6] Incomplete L1 Message * [7] Incomplete L2a Message * [8] NA * [9] TTCrx Address Error (not X”0003”) * [10] Spurious L0 * [11] Missing L0 * [12] Spurious L1 * [13] Boundary L1 * [14] Missing L1 * [15] L1 message arrives outside legal timeslot * [16] L1 message missing/timeout * [17] L2 message arrives outside legal timeslot * [18] L2 message missing/timeout * [19] Boundary L2 Message * [20] NA * [21] Prepulse error (=0; possible future use) * [22] L1 message content error * [23] L2 message content error * [24] NA |- | L1_MessageHeader[11:0] | 0x3030 | R | Debug: Latest received L1 Message |- | L1_MessageData1[11:0] | 0x3031 | R | Debug: Latest received L1 Message |- | L1_MessageData2[11:0] | 0x3032 | R | Debug: Latest received L1 Message |- | L1_MessageData3[11:0] | 0x3033 | R | Debug: Latest received L1 Message |- | L1_MessageData4[11:0] | 0x3034 | R | Debug: Latest received L1 Message |- | L2aMessageHeader[11:0] | 0x3035 | R | Debug: Latest received L2a Message |- | L2aMessageData1[11:0] | 0x3036 | R | Debug: Latest received L2a Message |- | L2aMessageData2[11:0] | 0x3037 | R | Debug: Latest received L2a Message |- | L2aMessageData3[11:0] | 0x3038 | R | Debug: Latest received L2a Message |- | L2aMessageData4[11:0] | 0x3039 | R | Debug: Latest received L2a Message |- | L2aMessageData5[11:0] | 0x303A | R | Debug: Latest received L2a Message |- | L2aMessageData6[11:0] | 0x303B | R | Debug: Latest received L2a Message |- | L2aMessageData7[11:0] | 0x303C | R | Debug: Latest received L2a Message |- | L2rMessageHeader[11:0] | 0x303D | R | Debug: Latest received L2r Message |- | RoIMessageHeader[11:0] | 0x303E | R | Debug: Latest received RoI Message |- | RoIMessageData1[11:0] | 0x303F | R | Debug: Latest received RoI Message |- | RoIMessageData2[11:0] | 0x3040 | R | Debug: Latest received RoI Message |- | RoIMessageData3[11:0] | 0x3041 | R | Debug: Latest received RoI Message |- | FIFO_read_enable | 0x3080 | T | Debug: Triggers a readout pulse to FIFO |- | FIFO_DAQHeader[31:0] | 0x3081 | R | Debug: Output of FIFO |} 5f573739a63256fd4d556c925e7601ec82a06125 1804 1803 2012-04-24T07:37:45Z Nfyku 4 wikitext text/x-wiki {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Busy Box Status and Control Registers |- !width="170"|Name !Address !Mode !Description !Default Value |- |TX module(15:0) |0x0001 |RW |For sending messages to DRORCs. * Bit 7:0 is TX data. * Bit 15:8 gives channelnumber in hexadecimal. Any value greater than the actual number of channels will result in a broadcast on all channels. |0x0000 |- |RX memory |0x1000-0x1FFF |RW |Memory where all messages received from DRORCs will be stored. One message is stored over 4 addresses: * Address ending "00" - 0x0 & RequestID(3:0) & OrbitID(23:16) * Address ending "01" - OrbitID(15:0) * Address ending "10" - 0x0 BunchCountID(11:0) * Address ending "11" - DRORCID(7:0) & ChannelNumber(7:0) |0x0000 |- |RX memory pointer(13:0) |0x2000 |R |Holds the value where the next message will be written in RX memory. The RX memory pointer will increase by 4 for each message. |0x0000 |- |EventID FIFO count(3:0) |0x2001 |R |Number of eventIDs stored in the FIFO, excluding the eventID currently being matched, if any. |0x0000 |- |Current EventID(35:32) |0x2002 |R |rowspan="3"|The EventID which is currently being matched. |0x0000 |- |Current EventID(31:16) |0x2003 |R |0x0000 |- |Current EventID(15:0) |0x2004 |R |0x0000 |- |Newest EventID(35:32) |0x2005 |R |rowspan="3"|The EventID most recently received from the Trigger system. |0x0000 |- |Newest EventID(31:16) |0x2006 |R |0x0000 |- |Newest EventID(15:0) |0x2007 |R |0x0000 |- |L1 Trigger Timeout(15:0) |0x2008 |RW |Time in 10 us resolution the 'busy' will be asserted after an L1A trigger. Note: The busy will not be deasserted if the buffers are full. |0x000A |- |Busy Condition(15:0) |0x2009 |RW |Status and control registers concerning the BUSY generation * Bit 15 - Busy because TTCrx_ready is low. * Bit 14 - Busy because MEB count >= MEB limit * Bit 13 - Busy because L1 timeout is active. * Bit 12 - Busy because Trigger Receiver Module is busy receiving a sequence. * Bit 11 - Busy because the maximum Trigger Burst length has been exceeded. * Bit 10 - Busy because two buffers are, or have been used, in new sparse mode * Bit 9:8 - Unused * Bit 7:4 - Current MEB count. * Bit 3:0 - MEB Limit: Limit for the maximum number of MEBs to count before busy will be asserted. |0x0000 |- |Halt FSM matching(0) |0x200A |RW |If LSB is set to 1 the internal State Machine (FSM) will halt in a wait state and will stop requesting EventIDs from the DRORCs. |0x0001 |- |Force match(0) |0x200B |T |Writing 0x1 when FSM halt is set, will force the FSM to move on to the next EventID even if it is not matched. Note : FSM must be halted before this has any effect. |N/A |- |Re-Request Timeout(15:0) |0x200C |RW |Number of clock cycles (25 ns) to wait in between sending requests to the DRORCs. |0x07FF |- |Current RequestID(3:0) |0x200D |R |Holds the RequestID the BusyBox is using to request eventIDs from the DRORCs. |0x0000 |- |Retry Count(15:0) |0x200E |R |Number of times the FSM has sent requests to DRORCs. Will reset to 0 for start of every eventID. |0x0000 |- |Busy time(31:16) |0x2010 |R |rowspan="2"|Holds value of counter for number of clock cycles BUSY has been asserted. |0x0000 |- |Busy time(15:0) |0x2011 |R |0x0000 |- |RX mem filter(15:0) |0x2012 |RW |Allows filtering of messages that are stored in RX memory. *Bit 7:0 is the pattern that will be matched with the channelnumber of the message. *Bit 15:8 allows enableing matching of individual bits 7-0. |0x0000 |- |Number of Channels |0x2014 |R |Number of channels (in hexadecimal) the firmware includes. This is a generic set at compile-time. |N/A |- |Firmware Revision |0x2015 |R |Firmware revision in hexadecimal. Holds the revision number of the source in SVN that this FW was compiled from. Current : 54 |0x0036 |- |Stresstest Enable(0) |0x2016 |RW |Duplicates input on channel 0 to all other channels. Used for testing the device with all channels enabled when only one physical DRORC is available. |0x0000 |- |Burst Size(5:0) |0x2017 |RW |The maximum burst size. A value of 0 disables the Burst Interlock feature. Maximum value is 63. |0x0000 |- |Burst Interlock Leak Time(15:0) |0x2018 |RW |Leak time for the Burst Interlock "leaky bucket" defined in steps of 10 us. Maximum leak time is 655.4 ms. |0x0000 |- |Trigger Mode(2:0) |0x2019 |RW |Control registers concerning the BUSY/trigger mode * Bit 2 - Not used * Bit 1 - New sparse mode enabled * Bit 0 - Not used |0x0000 |- |Current Trigger Event Info(12:0) |0x2050 |R |Holds the Event Info for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(24:16) |0x2051 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Current Trigger Event Error(15:0) |0x2052 |R |Holds the Event Error for current eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Info(12:0) |0x2054 |R |Holds the Event Info for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(24:16) |0x2055 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Newest Trigger Event Error(15:0) |0x2056 |R |Holds the Event Error for newest eventID as reported by the TRM. See TRM registers for bitmapping. |0x0000 |- |Channel Registers |0x21XX |RW |'XX' in the address gives the channelnumber in hexadecimal. *Bit 0 is enable(1)/disable(0) *Bit 1 indicates that the current EventID has been matched on this channel. |0x0001 |- |} {|border="1" cellpadding="5" cellspacing="0" !colspan="5"| Trigger Receiver Module Status and Control Registers |- !width="170"|Name !Address !Mode !width="90"|Bit slice !Description |---- |rowspan="11"|Control |rowspan="11"|0x3000 |RW |[15:13] |Unused |---- |RW |[12] |Trigger Input Mask Enable. Default=0 |---- |RW |[11] |L1a message mask. Default=1 |---- |RW |[10] |L2 Timeout FIFO storage mask. Default=1 |---- |RW |[9] |L2r FIFO storage mask. Default=1 |---- |RW |[8] |L2a FIFO storage mask. Default=1 |---- |RW |[7:4] |Unused |---- |RW |[3] |L0 support. Default=1 |---- |RW |[2] |Unused |---- |RW |[1] |Disable_error_masking. Default=0 |---- |RW |[0] |Serial B channel on/off. Default=1 |---- |rowspan="6"|Control |rowspan="6"|0x3001 |R |[15:8] |Trigger Receiver Version. Default=0x16 |---- |R |[7:4] |CDH version. Default=0x2 |---- |R |[3] |Not used |---- |R |[2] |Busy (receiving sequence) - |---- |R |[1] |Run Active - |---- |R |[0] |Bunch_counter overflow - |---- |Module Reset |0x3002 |T |N/A |Reset Module |---- |Reset Counters |0x3008 |T |N/A |Write to this registers will reset the counters in the module |---- |Issue Testmode |0x300A |T |N/A |Debug: Issues testmode sequence. Note that serialB channel input MUST be disabled when using this feature. |---- |rowspan="2"|L1_Latency |rowspan="2"|0x300C |RW |[15:12] |Uncertainty region +- N. default value 0x2 (50 ns) |---- |RW |[11:0] |Latency from L0 to L1. default value 0x0D4 (5.3 us) |---- |L2_Latency MAX |0x300E |RW |[15:0] |Max Latency from BC0 to L2. default value 0x4E20 (500 us) |---- |L2_Latency MIN |0x300F |RW |[15:0] |Min Latency from BC0 to L2. default value 0x0C80 (80 us) |---- |L1_msg_latency MAX |0x3014 |RW |[15:0] |Max Latency from BC0 to L1 msg. default value 0x0028 (1 us) |---- |L1_msg_latency MIN |0x3015 |RW |[15:0] |Min Latency from BC0 to L1 msg. default value 0x0F8 (6.2 us) |---- |Pre_pulse_counter |0x3016 |R |[15:0] |Number of decoded pre-pulses. |---- |BCID_Local |0x3018 |R |[11:0] |Number of bunchcrossings at arrival of L1 trigger. |---- |L0_counter |0x301A |R |[15:0] |Number of L0 triggers |---- |L1_counter |0x301C |R |[15:0] |Number of L1 triggers |---- |L1_msg_counter |0x301E |R |[15:0] |Number of successfully decoded L1 messages |---- |L2a_counter |0x3020 |R |[15:0] |Number of successfully decoded L2a messages |---- |L2r_counter |0x3022 |R |[15:0] |Number of successfully decoded L2r messages |---- |Bunchcounter |0x3026 |R |[11:0] |Debug: Number of bunchcrossings |---- |SingleHammingErrorCnt |0x302C |R |[15:0] |Number of single bit hamming errors |---- |DoubleHammingErrorCnt |0x302D |R |[15:0] |Number of double bit hamming errors |---- |MsgDecodingErrorCnt |0x302E |R |[15:0] |Number of message decoding errors |---- |SeqTimoutErrorCnt |0x302F |R |[15:0] |Number of errors related to sequence and timeouts. |---- |Buffered_events |0x3040 |R |[4:0] |Number of events stored in the FIFO. |---- |DAQ_Header01 |0x3042 |R |[15:0] |Latest received DAQ Header 1 [15:0] |---- |DAQ_Header01 |0x3043 |R |[15:0] |Latest received DAQ Header 1 [31:16] |---- |DAQ_Header02 |0x3044 |R |[15:0] |Latest received DAQ Header 2 [15:0] |---- |DAQ_Header02 |0x3045 |R |[15:0] |Latest received DAQ Header 2 [31:16] |---- |DAQ_Header03 |0x3046 |R |[15:0] |Latest received DAQ Header 3 [15:0] |---- |DAQ_Header03 |0x3047 |R |[15:0] |Latest received DAQ Header 3 [31:16] |---- |DAQ_Header04 |0x3048 |R |[15:0] |Latest received DAQ Header 4 [15:0] |---- |DAQ_Header04 |0x3049 |R |[15:0] |Latest received DAQ Header 4 [31:16] |---- |DAQ_Header05 |0x304a |R |[15:0] |Latest received DAQ Header 5 [15:0] |---- |DAQ_Header05 |0x304b |R |[15:0] |Latest received DAQ Header 5 [31:16] |---- |DAQ_Header06 |0x304c |R |[15:0] |Latest received DAQ Header 6 [15:0] |---- |DAQ_Header06 |0x304d |R |[15:0] |Latest received DAQ Header 6 [31:16] |---- |DAQ_Header07 |0x304e |R |[15:0] |Latest received DAQ Header 7 [15:0] |---- |DAQ_Header07 |0x304f |R |[15:0] |Latest received DAQ Header 7 [31:16] |---- |Event_info |0x3050 |R |[12:0] |Latest Received Event information: |---- |colspan="2" rowspan="10"| |R |[12] |Include payload |---- |R |[11] |Event has L2 Accept trigger |---- |R |[10] |Event has L2 Reject trigger |---- |R |[9] |Calibration trigger event |---- |R |[8] |Software trigger event |---- |R |[4:7] |Calibration/SW trigger type (= RoC) |---- |R |[3] |NA(=‘0’) |---- |R |[2] |NA(=‘0’) |---- |R |[1] |Region of Interest announced (=ESR) |---- |R |[0] |NA(=’0’) |---- |Event_error |0x3052 |R |[15:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="16"| |R |[15] |L1 message arrives outside legal timeslot |---- |R |[14] |Missing L1 |---- |R |[13] |Boundary L1 |---- |R |[12] |Spurious L1 |---- |R |[11] |Missing L0 |---- |R |[10] |Spurious L0 |---- |R |[9] |TTCrx Address Error (not X”0003”) |---- |R |[8] |NA (= ‘0’) |---- |R |[7] |Incomplete L2a Message |---- |R |[6] |Incomplete L1 Message |---- |R |[5] |Unknown Message Address Received |---- |R |[4] |Double Bit Hamming Error Broadcast. |---- |R |[3] |Single Bit Hamming Error Broadcast. |---- |R |[2] |Double Bit Hamming Error Individually Addr. |---- |R |[1] |Single Bit Hamming Error Individually Addr. |---- |R |[0] |Serial B Stop Bit Error |---- |Event_error |0x3053 |R |[8:0] |Latest Received Event error conditions: |---- |colspan="2" rowspan="9"| |R |[8] |NA (= ‘0’) |---- |R |[7] |L2 message content error |---- |R |[6] |L1 message content error |---- |R |[5] |Prepulse error (=0; possible future use) |---- |R |[4] |NA (= ‘0’) |---- |R |[3] |NA (= ‘0’) |---- |R |[2] |L2 message missing/timeout |---- |R |[1] |L2 message arrives outside legal timeslot |---- |R |[0] |L1 message missing/timeout |---- |} 88d24a05c8039389de174bcca9fff04dc39e054f 0 25 1805 1712 2012-06-28T09:25:36Z Vho026 70 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) [[Category:Mikroelektronikk]] 392b221e98511ef27bd3b91dd77f8e2e86ebd4e9 0 410 1806 2012-06-28T09:38:56Z Vho026 70 Created page with '== XJDeveloper == Dette er ei innføring i XJDeveloper. Tilhøyrande dokumentasjon er meint brukt til XJDemo Board versjon 1.2. === Dokumentasjonsmappa === Dokumentasjonsmpappa…' wikitext text/x-wiki == XJDeveloper == Dette er ei innføring i XJDeveloper. Tilhøyrande dokumentasjon er meint brukt til XJDemo Board versjon 1.2. === Dokumentasjonsmappa === Dokumentasjonsmpappa inneheld: * Krinsskjema * Bilete av demokort v.1.2. * Demokort-netliste * Diverse test-filer * Device-filer === Sette opp kortet === Det fyrste som gjerast er å kople demokortet til datamaskina gjennom XJ Link. Bruk ein av USB-inngongane på baksida av maskina. Deretter må det lagast ei prosjektmappe, som skal innehalde alle filene som vert laga. Mappe-plasseringa speler inga rolle. For å starte XJDeveloper: start>Programs>XJTAG 2.4>XJDeveloper. Lag eit nytt prosjekt, og lagre det i prosjektmappa. Gje prosjektet namnet "demo". Når dette er gjort, dukker dialogboksen "Add board" automatisk opp. I denne boksen gjev du kortet namn, og du gjev XJDeveloper netlista til demokortet. Gje kortet namnet "XJDemo". Netlista finn du i dokumentasjonsmappa - demo.net I tillegg har vi ei BOM-fil, som gjev XJDeveloper tilleggsinformasjon om komponentane på kortet. Denne fila er ikkje strengt naudsynt, men er nyttig. I dokumentasjonen finn du BOM-fila - demo.bom Legg til BOM-fila under BOM-settings. Etter å ha trykka next, set du tredje kolonne til å vere "Device Reference", fjerne kolonne "Value", og siste kolonne til "Device Description". Save. Under Power/Ground Nets i Setup-menyen i venstre marg er det to nett, 3.3V og GND. Dra desse to neta over i riktig kolonne til høgre. No veit XJTAG kva nett som er power og jord, og vil ikkje forsøke å skrive til desse. ==== Identifisere komponentane ==== Neste steg er å identifisere JTAG-kjeden. Trykk på add i Chain Setup. Til høgre for TDI, trykker du på select og vel CN1, pin 5. Trykk OK. Så kjem IC2.B3 opp i Select Next Pin-vinduet. Dra denne ned i JTAG Devices-lista. Trykk på Browse, og velg fila med same namn som IC2, altså XC9536XL_cs48.bsd Gjer det same med IC3.1, 3032at44.bsd. Begge desse filene finst i dokumentasjonsmappa. Neste steget er ein resistor, R49. Dra denne ned i JTAG-Devices-lista, men velg Connect device i den øvste fana. Så vel du Create file. Namngje fila Resistor, og connect 1 til 2. Til slutt kjem IC1.13. Høgreklikk og set denne til TDO. Save. No har vi etablert JTAG-kjeden. Deretter skal vi kategorisere non-JTAG-devices. Under Categorise Devices-fana i venstremargen, finn vi alle komponentane(devices), og ingen er endå kategoriserte. * Risistorane som er markerte med "Suggested Series Resistors" kategoriserer vi som passive komponentar. Dra alle over i "Passive", og velg Resistor.pdd som allereie er laga. * Alle jumperane på krinsen lar vi og vere passive. Gje jumperane[1,2,3,5,6] namn [jumper1,jumper2,...,jumper6] når vi lager filer til desse. For jumper[1,2,3] ser vi frå krinsteikninga at desse er meint kopla. Kople difor pinane 1-2,3-4,5-6,7-8 for desse tre jumperane. Jumper5 og jumper6 skal vere opne. * Alle pull-resistorane kategoriserer vi óg som passive. Når vi skal lage PDD-filer for desse, gjer vi som ved serie-motstanden, bortsett frå at vi skiftar frå Connect->Pull. Connect 1-2. ** No er det dukka opp ein siste resistor, R26. Legg denne til i resistor.pdd. * Under Ignore Devices legg vi kondensatorane, connectorane og "Other Resistors". I tillegg legg vi Switch1 under ignore(denne kjem vi attende til). * Under Test Devices legg vi til IC4,IC5, alle diodane, SW2 og SW3. IC4 gjev vi namnet EEPROM, IC5 gjev vi namnet SRAM, diodane gjev vi namnet LED, SW2 gjev vi namnet pushbutton1 og SW3 gjev vi namnet pushbutton2. * Under Logic Devices legg vi IC1. Frå krinsteikninga finn vi kva komponent IC1 er, og gjev XJDeveloper informasjon om det. Det neste steget er å identifiserer tilkoplingspinnane. Under Pin Mapping ser vi JTAG connectoren. Frå krinsteikninga finn vi korleis denne skal bestemmast(CN1). Dei pinnane som ikkje er gjevne namn i krinsteikninga, lar vi vere "input". === Testing === Det siste steget er å klargjere for test. Under Run and Deploy, finn ein fana XJRunnet Setup. Velg New>Add Global Function>CONNTEST. Gje testen eit fornuftig namn. Save. For å køyre testane som er sett opp under XJRunner-fana, trykk på Run Test-fana, og køyr testen. Når vi tester, ser vi at vi får opp ein short mellom to "created" net på IC2. Desse to neta finst på krinsen, men er ikkje med i netlista. For å be XJDeveloper sjå vekk i frå denne feilen, kople dei to neta saman. Det kan gjerast under fana Connections i venstremargen. Trykk på Add, velg Pin to Pin, og kople dei to neta saman. For å komme unna problemet med at GP1 er stuck at 1/0, går vi inn på Constant Pins-fana og set denne pinen til anten High/Low. Hugs å fysisk sett brytaren SW1 anten High/Low. Viss alt er sett riktig opp, skal vi ikkje lenger få feilmeldingar når vi køyrer testen. For å gje oss høve til å lage feil, er kortet utstyrt med jumperar. Sjå på krinsteikninga, og lag stuck at 0/1, kortslutningsfeil og brotfeil. ==== Minnetest(SRAM) ==== XJDeveloper har laga ei fil SRAM.xje frå informasjonen vi har gjeve programmet. For å kunne bruke ein ferdiglaga, enkel minnestest, modifiserer vi denne fila til å passe med testen. I dokumentasjonsmappa finn du fila SRAM.txt. Erstatt innhaldet i SRAM.xje med SRAM.txt. Den første, og enkle, minnetesten, ligg ligra i dokumentasjonsmappa - SRAM_test.txt. Kopier innhaldet i denne fila, og lim det inn Test Editor. Test Editor er eit av vindauga under Test Device Files-fana i venstremargen. Save. Lag så ein ny test i XJRunner-fana. Velg Add Device Function>IC5>Test. Gje testen eit fornuftig namn. XJTAG har vedlagt demokortdokumentasjonen gjeve oss ein meir utfyllande minnetest. Denne er vedlagt i dokumentasjonsmappa, og heiter memtestSRAM.xje. For å bruke denne, fjerner vi IC5 frå Categorise Devices og deretter SRAM-fila frå Test Device Files. Så kan vi legge IC5 til igjen, men velge Other Device File i staden for Create File. Velg fila som heiter SRAM_SOP28.xje. No kan du køyre testen på nytt. ==== EEPROM-test ==== Vedlagt i dokumentasjonen er fila 24LC23A.xje. Dette er testfila til IC4 - EEPROM. Kopier innhaldet i 24LC23A.xje inn i "Test Editor" under EEPROM i venstremargs-fana Test Device Files. Save. Då får ein to feilmeldingar, fordi funksjonane testen refererer til manglar. Desse finst i IIC.xje, som òg ligg i dokumentasjonen. Under Additional Code Files legg du IIC.xje til EEPROM. Save. På same måte som for SRAM-testen, må vi lage ein EEPROM-test under XJRunner-fana. No kan du køyre testen på nytt. 336babd54f1aca88bba3775be2a47a5747511feb 1807 1806 2012-06-28T11:14:15Z Vho026 70 wikitext text/x-wiki == XJDeveloper == Dette er ei innføring i XJDeveloper. Tilhøyrande dokumentasjon er meint brukt til XJDemo Board versjon 1.2. === Dokumentasjonsmappa === Dokumentasjonsmpappa inneheld: * Krinsskjema * Bilete av demokort v.1.2. * Demokort-netliste * Diverse test-filer * Device-filer === Sette opp kortet === Det fyrste som gjerast er å kople demokortet til datamaskina gjennom XJ Link. Bruk ein av USB-inngongane på baksida av maskina. Deretter må det lagast ei prosjektmappe, som skal innehalde alle filene som vert laga. Mappe-plasseringa speler inga rolle. For å starte XJDeveloper: start>Programs>XJTAG 2.4>XJDeveloper. Lag eit nytt prosjekt, og lagre det i prosjektmappa. Gje prosjektet namnet "demo". Når dette er gjort, dukker dialogboksen "Add board" automatisk opp. I denne boksen gjev du kortet namn, og du gjev XJDeveloper netlista til demokortet. Gje kortet namnet "XJDemo". Netlista finn du i dokumentasjonsmappa - demo.net I tillegg har vi ei BOM-fil, som gjev XJDeveloper tilleggsinformasjon om komponentane på kortet. Denne fila er ikkje strengt naudsynt, men er nyttig. I dokumentasjonen finn du BOM-fila - demo.bom Legg til BOM-fila under BOM-settings. Etter å ha trykka next, set du tredje kolonne til å vere "Device Reference", fjerne kolonne "Value", og siste kolonne til "Device Description". Save. Under Power/Ground Nets i Setup-menyen i venstre marg er det to nett, 3.3V og GND. Dra desse to neta over i riktig kolonne til høgre. No veit XJTAG kva nett som er power og jord, og vil ikkje forsøke å skrive til desse. ==== Identifisere komponentane ==== Neste steg er å identifisere JTAG-kjeden. Trykk på add i Chain Setup. Til høgre for TDI, trykker du på select og vel CN1, pin 5. Trykk OK. Så kjem IC2.B3 opp i Select Next Pin-vinduet. Dra denne ned i JTAG Devices-lista. Trykk på Browse, og velg fila med same namn som IC2, altså XC9536XL_cs48.bsd Gjer det same med IC3.1, 3032at44.bsd. Begge desse filene finst i dokumentasjonsmappa. Neste steget er ein resistor, R49. Dra denne ned i JTAG-Devices-lista, men velg Connect device i den øvste fana. Så vel du Create file. Namngje fila Resistor, og connect 1 til 2. Til slutt kjem IC1.13. Høgreklikk og set denne til TDO. Save. No har vi etablert JTAG-kjeden. Deretter skal vi kategorisere non-JTAG-devices. Under Categorise Devices-fana i venstremargen, finn vi alle komponentane(devices), og ingen er endå kategoriserte. * Risistorane som er markerte med "Suggested Series Resistors" kategoriserer vi som passive komponentar. Dra alle over i "Passive", og velg Resistor.pdd som allereie er laga. * Alle jumperane på krinsen lar vi og vere passive. Gje jumperane[1,2,3,5,6] namn [jumper1,jumper2,...,jumper6] når vi lager filer til desse. For jumper[1,2,3] ser vi frå krinsteikninga at desse er meint kopla. Kople difor pinane 1-2,3-4,5-6,7-8 for desse tre jumperane. Jumper5 og jumper6 skal vere opne. * Alle pull-resistorane kategoriserer vi óg som passive. Når vi skal lage PDD-filer for desse, gjer vi som ved serie-motstanden, bortsett frå at vi skiftar frå Connect->Pull. Connect 1-2. ** No er det dukka opp ein siste resistor, R26. Legg denne til i resistor.pdd. * Under Ignore Devices legg vi kondensatorane, connectorane og "Other Resistors". I tillegg legg vi Switch1 under ignore(denne kjem vi attende til). * Under Test Devices legg vi til IC4,IC5, alle diodane, SW2 og SW3. IC4 gjev vi namnet EEPROM, IC5 gjev vi namnet SRAM, diodane gjev vi namnet LED, SW2 gjev vi namnet pushbutton1 og SW3 gjev vi namnet pushbutton2. * Under Logic Devices legg vi IC1. Frå krinsteikninga finn vi kva komponent IC1 er, og gjev XJDeveloper informasjon om det. Det neste steget er å identifiserer tilkoplingspinnane. Under Pin Mapping ser vi JTAG connectoren. Frå krinsteikninga finn vi korleis denne skal bestemmast(CN1). Dei pinnane som ikkje er gjevne namn i krinsteikninga, lar vi vere "input". === Testing === Det siste steget er å klargjere for test. Under Run and Deploy, finn ein fana XJRunnet Setup. Velg New>Add Global Function>CONNTEST. Gje testen eit fornuftig namn. Save. For å køyre testane som er sett opp under XJRunner-fana, trykk på Run Test-fana, og køyr testen. Når vi tester, ser vi at vi får opp ein short mellom to "created" net på IC2. Desse to neta finst på krinsen, men er ikkje med i netlista. For å be XJDeveloper sjå vekk i frå denne feilen, kople dei to neta saman. Det kan gjerast under fana Connections i venstremargen. Trykk på Add, velg Pin to Pin, og kople dei to neta saman. For å komme unna problemet med at GP1 er stuck at 1/0, går vi inn på Constant Pins-fana og set denne pinen til anten High/Low. Hugs å fysisk sett brytaren SW1 anten High/Low. Viss alt er sett riktig opp, skal vi ikkje lenger få feilmeldingar når vi køyrer testen. For å gje oss høve til å lage feil, er kortet utstyrt med jumperar. Sjå på krinsteikninga, og lag stuck at 0/1, kortslutningsfeil og brotfeil. ==== Minnetest(SRAM) ==== XJDeveloper har laga ei fil SRAM.xje frå informasjonen vi har gjeve programmet. For å kunne bruke ein ferdiglaga, enkel minnestest, modifiserer vi denne fila til å passe med testen. I dokumentasjonsmappa finn du fila SRAM.txt. Erstatt innhaldet i SRAM.xje med SRAM.txt. Den første, og enkle, minnetesten, ligg lagra i dokumentasjonsmappa - SRAM_test.txt. Kopier innhaldet i denne fila, og lim det inn Test Editor. Test Editor er eit av vindauga under Test Device Files-fana i venstremargen. Save. Lag så ein ny test i XJRunner-fana. Velg Add Device Function>IC5>Test. Gje testen eit fornuftig namn. XJTAG har vedlagt demokortdokumentasjonen gjeve oss ein meir utfyllande minnetest. Denne er vedlagt i dokumentasjonsmappa, og heiter memtestSRAM.xje. For å bruke denne, fjerner vi IC5 frå Categorise Devices og deretter SRAM-fila frå Test Device Files. Så kan vi legge IC5 til igjen, men velge Other Device File i staden for Create File. Velg fila som heiter SRAM_SOP28.xje. No kan du køyre testen på nytt. ==== EEPROM-test ==== Vedlagt i dokumentasjonen er fila 24LC23A.xje. Dette er testfila til IC4 - EEPROM. Kopier innhaldet i 24LC23A.xje inn i "Test Editor" under EEPROM i venstremargs-fana Test Device Files. Save. Då får ein to feilmeldingar, fordi funksjonane testen refererer til manglar. Desse finst i IIC.xje, som òg ligg i dokumentasjonen. Under Additional Code Files legg du IIC.xje til EEPROM. Save. På same måte som for SRAM-testen, må vi lage ein EEPROM-test under XJRunner-fana. No kan du køyre testen på nytt. cb81d7006e30de2d9b14963c5c74c6c53d3905b1 1808 1807 2012-06-28T11:26:15Z Vho026 70 wikitext text/x-wiki == XJDeveloper == Dette er ei innføring i XJDeveloper. Tilhøyrande dokumentasjon er meint brukt til XJDemo Board versjon 1.2. === Dokumentasjonsmappa === Dokumentasjonsmpappa inneheld: * Krinsskjema * Bilete av demokort v.1.2. * Demokort-netliste * Diverse test-filer * Device-filer === Sette opp kortet === Det fyrste som gjerast er å kople demokortet til datamaskina gjennom XJ Link. Bruk ein av USB-inngongane på baksida av maskina. Deretter må det lagast ei prosjektmappe, som skal innehalde alle filene som vert laga. Mappe-plasseringa speler inga rolle. For å starte XJDeveloper: start>Programs>XJTAG 2.4>XJDeveloper. Lag eit nytt prosjekt, og lagre det i prosjektmappa. Gje prosjektet namnet "demo". Når dette er gjort, dukker dialogboksen "Add board" automatisk opp. I denne boksen gjev du kortet namn, og du gjev XJDeveloper netlista til demokortet. Gje kortet namnet "XJDemo". Netlista finn du i dokumentasjonsmappa - demo.net I tillegg har vi ei BOM-fil, som gjev XJDeveloper tilleggsinformasjon om komponentane på kortet. Denne fila er ikkje strengt naudsynt, men er nyttig. I dokumentasjonen finn du BOM-fila - demo.bom Legg til BOM-fila under BOM-settings. Etter å ha trykka next, set du tredje kolonne til å vere "Device Reference", fjerne kolonne "Value", og siste kolonne til "Device Description". Save. Under Power/Ground Nets i Setup-menyen i venstre marg er det to nett, 3.3V og GND. Dra desse to neta over i riktig kolonne til høgre. No veit XJTAG kva nett som er power og jord, og vil ikkje forsøke å skrive til desse. ==== Identifisere komponentane ==== Neste steg er å identifisere JTAG-kjeden. Trykk på add i Chain Setup. Til høgre for TDI, trykker du på select og vel CN1, pin 5. Trykk OK. Så kjem IC2.B3 opp i Select Next Pin-vinduet. Dra denne ned i JTAG Devices-lista. Trykk på Browse, og velg fila med same namn som IC2, altså XC9536XL_cs48.bsd Gjer det same med IC3.1, 3032at44.bsd. Begge desse filene finst i dokumentasjonsmappa. Neste steget er ein resistor, R49. Dra denne ned i JTAG-Devices-lista, men velg Connect device i den øvste fana. Så vel du Create file. Namngje fila Resistor, og connect 1 til 2. Til slutt kjem IC1.13. Høgreklikk og set denne til TDO. Save. No har vi etablert JTAG-kjeden. Deretter skal vi kategorisere non-JTAG-devices. Under Categorise Devices-fana i venstremargen, finn vi alle komponentane(devices), og ingen er endå kategoriserte. * Risistorane som er markerte med "Suggested Series Resistors" kategoriserer vi som passive komponentar. Dra alle over i "Passive", og velg Resistor.pdd som allereie er laga. * Alle jumperane på krinsen lar vi og vere passive. Gje jumperane[1,2,3,5,6] namn [jumper1,jumper2,...,jumper6] når vi lager filer til desse. For jumper[1,2,3] ser vi frå krinsteikninga at desse er meint kopla. Kople difor pinane 1-2,3-4,5-6,7-8 for desse tre jumperane. Jumper5 og jumper6 skal vere opne. * Alle pull-resistorane kategoriserer vi óg som passive. Når vi skal lage PDD-filer for desse, gjer vi som ved serie-motstanden, bortsett frå at vi skiftar frå Connect->Pull. Connect 1-2. ** No er det dukka opp ein siste resistor, R26. Legg denne til i resistor.pdd. * Under Ignore Devices legg vi kondensatorane, connectorane og "Other Resistors". I tillegg legg vi Switch1 under ignore(denne kjem vi attende til). * Under Test Devices legg vi til IC4,IC5, alle diodane, SW2 og SW3. IC4 gjev vi namnet EEPROM, IC5 gjev vi namnet SRAM, diodane gjev vi namnet LED, SW2 gjev vi namnet pushbutton1 og SW3 gjev vi namnet pushbutton2. * Under Logic Devices legg vi IC1. Frå krinsteikninga finn vi kva komponent IC1 er, og gjev XJDeveloper informasjon om det. Det neste steget er å identifiserer tilkoplingspinnane. Under Pin Mapping ser vi JTAG connectoren. Frå krinsteikninga finn vi korleis denne skal bestemmast(CN1). Dei pinnane som ikkje er gjevne namn i krinsteikninga, lar vi vere "input". === Testing === Det siste steget er å klargjere for test. Under Run and Deploy, finn ein fana XJRunnet Setup. Velg New>Add Global Function>CONNTEST. Gje testen eit fornuftig namn. Save. For å køyre testane som er sett opp under XJRunner-fana, trykk på Run Test-fana, og køyr testen. Når vi tester, ser vi at vi får opp ein short mellom to "created" net på IC2. Desse to neta finst på krinsen, men er ikkje med i netlista. For å be XJDeveloper sjå vekk i frå denne feilen, kople dei to neta saman. Det kan gjerast under fana Connections i venstremargen. Trykk på Add, velg Pin to Pin, og kople dei to neta saman. For å komme unna problemet med at GP1 er stuck at 1/0, går vi inn på Constant Pins-fana og set denne pinen til anten High/Low. Hugs å fysisk sett brytaren SW1 anten High/Low. Viss alt er sett riktig opp, skal vi ikkje lenger få feilmeldingar når vi køyrer testen. For å gje oss høve til å lage feil, er kortet utstyrt med jumperar. Sjå på krinsteikninga, og lag stuck at 0/1, kortslutningsfeil og brotfeil. ==== Minnetest(SRAM) ==== XJDeveloper har laga ei fil SRAM.xje frå informasjonen vi har gjeve programmet. For å kunne bruke ein ferdiglaga, enkel minnestest, modifiserer vi denne fila til å passe med testen. I dokumentasjonsmappa finn du fila SRAM.txt. Erstatt innhaldet i SRAM.xje med SRAM.txt. Den første, og enkle, minnetesten, ligg lagra i dokumentasjonsmappa - SRAM_test.txt. Kopier innhaldet i denne fila, og lim det inn Test Editor. Test Editor er eit av vindauga under Test Device Files-fana i venstremargen. Save. Lag så ein ny test i XJRunner-fana. Velg Add Device Function>IC5>Test. Gje testen eit fornuftig namn. XJTAG har vedlagt demokortdokumentasjonen gjeve oss ein meir utfyllande minnetest. Denne er vedlagt i dokumentasjonsmappa, og heiter memtestSRAM.xje. For å bruke denne, høgreklikker vi på IC5 i Categorised Devices>Configure>Other Device File>SRAM_SOP24.xje. Dette legg automatisk memtestSRAM.xje til som tilleggskode. No kan testen køyrast på nytt. Bruk jumperane kring minnekrinsen til å lage feil. ==== EEPROM-test ==== Vedlagt i dokumentasjonen er fila 24LC23A.xje. Dette er testfila til IC4 - EEPROM. Kopier innhaldet i 24LC23A.xje inn i "Test Editor" under EEPROM i venstremargs-fana Test Device Files. Save. Då får ein to feilmeldingar, fordi funksjonane testen refererer til manglar. Desse finst i IIC.xje, som òg ligg i dokumentasjonen. Under Additional Code Files legg du IIC.xje til EEPROM. Save. På same måte som for SRAM-testen, må vi lage ein EEPROM-test under XJRunner-fana. No kan du køyre testen på nytt. c9b203075f083fb28fd95b8f61e722a5073031f1 0 317 1812 1757 2012-08-10T14:46:19Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== * [[Setting Up PetaLinux System]] * Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk petalinux_sdk] * [[Get readout box up and running]] * [[Programming Mimosa chips]] * [[Readout software]] [[Category:Mikroelektronikk]] b2353cbcb20bd55f2dc202eae44acde51cfaea94 1813 1812 2012-08-10T14:47:13Z Dfe002 7 wikitext text/x-wiki This page should contain information about the Focal project, especially about the interfacing from the Mimosa chips to the readout electronics. == Overview == [[Media:Focal readout.pdf|Simple description of the Alice Focal readout electronics]]. == Mimosa chips == * [[Media:PH1-UserMan-20080916.pdf|preliminary user manual of Phase1]] * [[Media:mimosa.bsd.txt|BSDL file of Phase1]], which can be used for JTAG test, such as with an XJTAG module. * [[Media:pattern_test.svf.txt|SVF file for pattern-only mode test of Phase1]], Use XJTAG to configure Phase1 chip with it, LVDS data output signals will appear on the 4 channels after supplying 160MHz differential clock and START signal. == Readout electronics == === Adapterboard /Fanoutboard === The adapterboard and fan-out boards provide LVDS interfaces and JTAG interfaces between the Control and Read-out board and the Mimosa ASICs. Here is [[Media:Focal_read-out_board_schematics.pdf|the schematics of the boards]]. * Spartan6 FPGA type: [http://www.xilinx.com/support/documentation/spartan-6.htm XC6SLX150-FGG676, speed-grade: 3] * Examples of user constraint files for Spartan6 FPGAs: [[Media:U1.ucf.txt| U1 ]],[[Media:U2.ucf.txt| U2 ]] * EXamples of VHDL entity definations for Spartan6 FPGAs: [[Media:U1.vhdl.txt| U1 ]],[[Media:U2.vhdl.txt| U2 ]] === Control and Readout board === The idea is to use a [http://www.xilinx.com/products/devkits/EK-V6-ML605-G.htm Xilinx Virtex 6 development board] as a first prototype. The board will run Petalinux, and some software to access the firmware registers. A software framework for the TPC detector is to be adapted for the use on the Virtex 6 board and Petalinux. *[[Media:ML605.ucf.txt|FPGA user constraint file for Virtex 6 development board]] ==== Firmware ==== The VHDL counterpart is to be found here: http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/alice-fw/trunk/messagebuffer/ ==== Software ==== * [[Setting Up PetaLinux System]] * Petalinux documentation: [http://www.petalogix.com/resources/documentation/petalinux_sdk petalinux_sdk] * [[Get readout box up and running]] * [[Programming Mimosa chips]] ==Readout software== [[Report by Tony]] [[Category:Mikroelektronikk]] b14ba707648f6ccdd1f9171f383cca1b69d73594 0 411 1814 2012-08-10T14:47:25Z Dfe002 7 Created page with 'blabla' wikitext text/x-wiki blabla bb21158c733229347bd4e681891e213d94c685be 0 331 1816 1771 2012-09-03T15:09:36Z Kmo078 65 Added link to astropart. phys page wikitext text/x-wiki == General Information == * [[What to do when you come to Bergen as a new student]] * [[What to do when you come to CERN for the first time]] * [[If you are a short time visitor]] * [[CTA information]] (how to get accounts, get on lists and access) * [[ATLAS information]] (how to get accounts, get on lists and access) == Useful links == * Our web-page: http://www.uib.no/People/hsa061/DAMARA/Welcome.html * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasComputing * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasPhysics * [[Terminology]] * [[Useful papers]] == Computing == When you have an ATLAS account you can work your way through this link: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBook When this is done you can try this one: * https://twiki.cern.ch/twiki/bin/view/AtlasProtected/PhysicsAnalysisWorkBook A set of tutorials can be found here: * https://twiki.cern.ch/twiki/bin/viewauth/Atlas/ComputingTutorials Root homepage with tutorials, downloads, etc. * http://root.cern.ch/drupal/ Other stuff: * [[Info about D3PD analysis variables]] * [[Useful Linux commands]] * [http://vic.gedris.org/Manual-ShellIntro/1.2/ShellIntro.pdf Small intro to Linux (pdf)] * [[Installing DarkSusy]] * [[Installing ISAJET]] * [[Astroparticle Physics]] == [[DamaraResults|Results]] == * [[DamaraResults#Outreach|Outreach]] * [[DamaraResults#Presentations|Presentations]] * [[DamaraResults#Publications|Publications]] * [[DamaraResults#Theses|Theses]] 9cb5ae2e8cd439cc5b5bd13465262e5e06aa9faa 0 412 1817 2012-09-03T15:13:34Z Kmo078 65 Lagde side wikitext text/x-wiki =Astroparticle physics= == Useful links == [http://viavca.in2p3.fr/site.html Virtual Institute of Astroparticle Physics] [http://ihp-lx2.ethz.ch/AstroTeilchen/ ETH Zürichs astropartikkel-fag] 0731c0061f5060a6e142824e4070151a97a30be1 1818 1817 2012-09-03T15:14:16Z Kmo078 65 wikitext text/x-wiki =Astroparticle physics= == Useful links == [http://viavca.in2p3.fr/site.html Virtual Institute of Astroparticle Physics] [http://ihp-lx2.ethz.ch/AstroTeilchen/ ETH Zürichs astropartikkel-fag] 1fcb3e56e5dae04abb9a6cff457b38fb3a257d12 1819 1818 2012-09-03T15:14:48Z Kmo078 65 wikitext text/x-wiki =Astroparticle physics= == Useful links == *[http://viavca.in2p3.fr/site.html Virtual Institute of Astroparticle Physics] *[http://ihp-lx2.ethz.ch/AstroTeilchen/ ETH Zürichs astropartikkel-fag] d21e36a67864fb747ccb738c5e0d664eb89fb0f8 1820 1819 2012-09-05T10:54:45Z Kmo078 65 Added list of topics wikitext text/x-wiki =Astroparticle physics= Astroparticle physics combines our knowledge of how fundamental particles interact with observations of our universe. Great advances in understanding the early universe has followed from this happy union. == Relevant topics == (with help from Prekins: Particle Astrophysics * Particles & Interactions ** * Cosmology ** * Astrophysical sources ** == Useful links == *[http://viavca.in2p3.fr/site.html Virtual Institute of Astroparticle Physics] *[http://ihp-lx2.ethz.ch/AstroTeilchen/ ETH Zürichs astropartikkel-fag] [[Category:Particle Physics]] acee008afa42e8e929caf01a957293a6bccfde95 1821 1820 2012-09-05T10:55:01Z Kmo078 65 wikitext text/x-wiki =Astroparticle physics= Astroparticle physics combines our knowledge of how fundamental particles interact with observations of our universe. Great advances in understanding the early universe has followed from this happy union. == Relevant topics == (with help from Prekins: Particle Astrophysics * Particles & Interactions ** * Cosmology ** * Astrophysical sources ** == Useful links == *[http://viavca.in2p3.fr/site.html Virtual Institute of Astroparticle Physics] *[http://ihp-lx2.ethz.ch/AstroTeilchen/ ETH Zürichs astropartikkel-fag] [[Category:Particle Physics, DAMARA]] 654a94c4dab9158428f9507ed3664a032fe03524 1822 1821 2012-09-05T11:23:01Z Kmo078 65 Added more in list of topics wikitext text/x-wiki =Astroparticle physics= Astroparticle physics combines our knowledge of how fundamental particles interact with observations of our universe. Great advances in understanding the early universe has followed from this happy union. == Relevant topics == (with help from Prekins: Particle Astrophysics * Particles & Interactions ** The standard model is largely covered by courses @ UIB- short review ** Beyond standard model overview *** Dark matter candidates *** Supersymmetry *** Others * Cosmology ** A summary of experimental evidence behind the cosmological standard model; \Lambda CDM ** The Friedmann equation + some GR review ** Energy density, size of universe,CMB radiation ** Particles in the early universe ** Nucleosynthesis & matter/antimatter asymmetry ** Dark matter *** Signatures *** Evidence *** Candidates ** Dark Energy ** Early structure formation * Astrophysical sources ** Cosmic particles ** Stars & Galaxies == Useful links == *[http://viavca.in2p3.fr/site.html Virtual Institute of Astroparticle Physics] *[http://ihp-lx2.ethz.ch/AstroTeilchen/ ETH Zürichs astropartikkel-fag] [[Category:Particle Physics]] 814ac837b9dd4e5554e85c324ddaadceda4d75f9 0 348 1823 1809 2012-09-21T13:19:18Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes * "Higgs-Mekanismen", presentasjon for Bergen Katedralskole (19.12.2011) Knut Morå * ''Den siste biten i puslespillet?'', Kronikk i Bergens tidende (05.09.2012), Trygve Buanes og Bjarne Stugu == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes * Thesis plans, Stockholm meeting [File:Stockholmpresentation120323.pdf] (12.mars 2012), Knut Morå == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844 ATL-COM-PHYS-2011-1619] (25. november 2011) == Theses == === Master === === PhD === 7d4a7ebec17351cb5ce1551687c666cd79a54d01 1824 1823 2012-10-01T14:25:12Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes * "Higgs-Mekanismen", presentasjon for Bergen Katedralskole (19.12.2011) Knut Morå * ''Den siste biten i puslespillet?'', Kronikk i Bergens tidende (05.09.2012), Trygve Buanes og Bjarne Stugu * ''Universets mørke sider'', Besøk fra Haram videregående skole (01.10.2012), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes * Thesis plans, Stockholm meeting [File:Stockholmpresentation120323.pdf] (12.mars 2012), Knut Morå * "CTA : Gamma line emission searches", [http://indico.cern.ch/conferenceDisplay.py?confId=205146 DAMARA Scientific Advisory Committee Meeting] (23.08.2012) * "CTA : Camera calibration test-setup and plans", [http://indico.cern.ch/conferenceDisplay.py?confId=205146 DAMARA Scientific Advisory Committee Meeting] (23.08.2012) == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844 ATL-COM-PHYS-2011-1619] (25. november 2011) == Theses == === Master === === PhD === 8a86971a908375934623748d656ed9c1d97164c0 1825 1824 2012-10-01T14:27:08Z St01355 57 wikitext text/x-wiki == Outreach == * ''Verdens største mikroskop – om ATLAS-eksperimentet på CERN'', [https://fft.uib.no/2011/02/28/program-for-nfk-2011/ Norske fysikkstudenters konferanse 2011] (13. mars 2011), Trygve Buanes * ''Masterprogrammer i partikkelfysikk'', [http://www.uib.no/ift/seminar/2011/03/fellesseminar-masterstudier-i-fysikk Fellesseminar/infomøte] (18. mars 2011), Trygve Buanes * ''Universets mørke sider'', Besøk fra Danielsen videregående skole (15. september), Trygve Buanes * ''Researcher's corner'', [http://www.vilvite.no/index.php?action=post&id=1054 Researchers' night] (23. september 2011), Trygve Buanes * ''Vitenskapens usanne "sannheter"'', [http://www.nrk.no/nyheter/1.7805749 nrk.no], (24. september 2011), Trygve Buanes * Interview with NTB, Norwegian news agency (15.6.2011), two articles, Heidi Sandaker * “Forskere - til datamaskinene”, [http://www.forskning.no/artikler/2011/april/284940], Forskning.no, (8.4.2011), Heidi Sandaker * Norwegian teachers program [http://indico.cern.ch/conferenceDisplay.py?confId=130206] (13-18.03.2011), Heidi Sandaker * “Skyter med antistråler”, På høyden og Forskning.no, [http://nyheter.uib.no/?modus=vis_nyhet&id=48331] (24.2.2011), Heidi Sandaker * Several guided tours for visitors at ATLAS and at CERN (2010 - 2011), Heidi Sandaker * Norwegian mini-winterschool (2-4.11.2011), Trygve Buanes og Heidi Sandaker * "Brutt lyshastigheten. Hva så?", Forskning.no (24.9.2011), Heidi Sandaker * "Hektisk blant verdens fysikere", Forskning.no (10.10.2011), Heidi Sandaker * Interview with Studentradioen i Bergen about the Nobel prize in physics (19.10.2011), Trygve Buanes * ''Universets mørke sider'', Bergen astronomiske forening (9. november), Trygve Buanes * "Higgs-Mekanismen", presentasjon for Bergen Katedralskole (19.12.2011) Knut Morå * ''Den siste biten i puslespillet?'', Kronikk i Bergens tidende (05.09.2012), Trygve Buanes og Bjarne Stugu * ''Universets mørke sider'', Besøk fra Haram videregående skole (01.10.2012), Trygve Buanes == Presentations == === Conferences === * ''Unified Dark Sector'', [https://wikihost.uib.no/ift/images/7/76/UDMOverview2.pdf Fysikermøtet 2011] (22. juni 2011), Jan Lindroos * Presentation at the CTA workshop in Toulouse, May 2011, Heidi Sandaker * ''Looking for light from dark matter'', [http://indico.cern.ch/conferenceDisplay.py?confId=194991 Faggruppemøte for subatomær fysikk og astrofysikk] (27.09.2012) === Seminars etc === * ''Raskere en lyset?'', [http://www.uib.no/ift/foredrag/2011/09/raskere-enn-lyset Fellesseminar, IFT, UiB] (30. september 2011), Trygve Buanes * ''The Phantom of the OPERA'', [http://www.ntnu.edu/web/physics/colloquia/-/asset_publisher/H96i/content/october-14?redirect=http%3a%2f%2fwww.ntnu.edu%2fweb%2fphysics%2fcolloquia%3fp_p_id%3d101_INSTANCE_H96i%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-3%26p_p_col_pos%3d3%26p_p_col_count%3d4 Fredagskollokvium, NTNU] (14. september 2011), Trygve Buanes === Working group meetings etc === * ''Signal optimisation studies'', [https://indico.cern.ch/conferenceTimeTable.py?confId=132275#20110414.detailed Rare b decays workshop] (14. april 2011), Trygve Buanes * ''Separation of ttbar and SUSY with kinematic fitting'', [https://indico.cern.ch/conferenceDisplay.py?confId=142345 Informal SUSY with taus] (8. juni 2011), Trygve Buanes * ''Update on KLFitter'', [https://indico.cern.ch/conferenceDisplay.py?confId=143208 Informal SUSY with taus] (15. juni 2011), Trygve Buanes * ''Study of CTA sensitivity for gamma line-emission searches'', [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Trygve Buanes * "mSUGRA high tan(beta) grid" [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Jan Lindroos * Plans for CTA membership, [http://www.mn.uio.no/astro/english/research/groups/cosmology/events/dm_meeting.html Norwegian Dark Matter Meeting] (21. october 2011), Heidi Sandaker * ''Update on 1tau analysis on rel17'', [https://indico.cern.ch/conferenceDisplay.py?confId=156610 Informal SUSY with taus] (1. november 2011), Trygve Buanes * Thesis plans, Stockholm meeting [File:Stockholmpresentation120323.pdf] (12.mars 2012), Knut Morå * "CTA : Gamma line emission searches", [http://indico.cern.ch/conferenceDisplay.py?confId=205146 DAMARA Scientific Advisory Committee Meeting] (23.08.2012) * "CTA : Camera calibration test-setup and plans", [http://indico.cern.ch/conferenceDisplay.py?confId=205146 DAMARA Scientific Advisory Committee Meeting] (23.08.2012) == Publications == === Journals === === Conference proceedings === === Internal notes === * ''Search for supersymmetry in the coannihilation region with taus, jets and missing transverse energy in the final state'', [http://cdsweb.cern.ch/record/1385579 ATL-COM-PHYS-2011-1304] (28. september 2011) * ''Limit on Bs → μμ based on 2.4 fb−1 of integrated luminosity'', [https://cdsweb.cern.ch/record/1401844 ATL-COM-PHYS-2011-1619] (25. november 2011) == Theses == === Master === === PhD === ccbbffd2bb100f63f14a79c4798003fab4606e4e 0 405 1826 1815 2012-11-16T13:51:34Z Kmo078 65 wikitext text/x-wiki Astroparticle ----------------------- * Investigating Gamma-Ray Lines from Dark Matter with Future Observatories: http://arxiv.org/abs/1207.6773 * Fermi-Lat: http://arxiv.org/abs/1205.2739 * Weniger: http://arxiv.org/abs/1204.2797 * Servant: http://arxiv.org/abs/0912.0004 * Profumo: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] 7628a24418832172c60b2dfcd1810a5ba05097fd 1833 1826 2013-04-16T12:31:52Z St01355 57 wikitext text/x-wiki Astroparticle ----------------------- * Investigating Gamma-Ray Lines from Dark Matter with Future Observatories: http://arxiv.org/abs/1207.6773 * Fermi-Lat: http://arxiv.org/abs/1205.2739 * Weniger: http://arxiv.org/abs/1204.2797 * Servant: http://arxiv.org/abs/0912.0004 * Profumo: http://inspirebeta.net/record/901431 * Ellis: http://arxiv.org/pdf/1112.3564.pdf * Olga Bessidskaia master thesis: [[File:RapportOlgaMaster.pdf]] * Hofmann et al: http://arxiv.org/abs/astro-ph/9908092 (Energy determination with IACT) 74cbc6866c367131a934ab40c03068b5e6fb9ae8 0 25 1827 1805 2013-02-15T10:51:30Z Tni071 73 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio]] Create a component symbol using a SPICE file * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) [[Category:Mikroelektronikk]] 770604487c7e5a305afa4751d6a48f5e8d5129a9 1828 1827 2013-02-15T10:52:20Z Tni071 73 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE Symbol]] Create a component symbol using a SPICE file * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) [[Category:Mikroelektronikk]] bde513d8f0be17f3260d7d5580dff4fd8cfa3d86 1831 1828 2013-02-15T11:50:07Z Tni071 73 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) [[Category:Mikroelektronikk]] fb18b8b3d7fb4ee48cde2c257416f9a62ecbd12b 1841 1831 2013-06-12T16:10:47Z Ave082 33 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[SmartFusion2]] Oppsett og design med SF2 [[Category:Mikroelektronikk]] 61882b01025f56bafa41ffb01548c1488efc5868 0 413 1829 2013-02-15T10:54:53Z Tni071 73 SPICE Symbol tutorial added wikitext text/x-wiki = Include a SPICE File in IC Studio = This is a description of how to download a spice file from the web and include it in your IC studio project. A symbol is created to represent the component described by the spice file, and the procedure of linking the spice file to your symbol is described (See the [[IC studio]] tutorial if you are new to symbols). The AD8000 opamp is used as an example throughout this tutorial. ==Download a SPICE File== Search the internet for a spice model, i.e. ``AD8000 spice model''. The vendor will normally provide such a file which can be downloaded. Open the file (ad8000p.cir) in a text editor and scroll down to the node assignments. The node assignments should match (identically) the pins of your soon to be created symbol. * Node assignments * non-inverting input * | inverting input * | | positive supply * | | | negative supply * | | | | output * | | | | | Power down * | | | | | | .SUBCKT AD8000 1 2 Vcc Vee Vout PD ==Create a Symbol== First you have to create a project library as explained in [[IC studio]]. In the cell view you should create a cell for your component which is of the view type ``symbol''. The next step is to start drawing your symbol with the desired shape and pins: Use the palette on the left side of the screen to draw lines, or use a predefined shape (i.e. a rectangle). From the same palette you can choose the ``Add Pin'' button. Choose the pin preferences as you find suitable, but note that the pin names must be identical to the node assignments in the spice file. Place your pins and create a nice symbol... ==Relate a SPICE File to a Symbol== Now you have a symbol, but it does not have any relation to the spice file except from the pin names. Right click on the cell you just made and add a new view of the type ``spice''. An almost blank spice file will pop up in the IC Studio text editor. Delete what is there and go to ``file->insert file`` and choose the spice file you have downloaded (you can also copy-paste the spice file) - save it. When you close the text editor, you will get a message: ''Spice File Changed - Do you want to change the top sub-circuit``? Press yes and select the desired sub-circuit name. The following message should appear in IC Studio: // Starting Spice registration ... please wait // Note: Registering SPICE model "AD8000" with symbol "ad8000" // Note: Registration succeeded Create a new cell with your top-level circuit (''schematic`` view). Now you can include the component by ''Right-click -> Instance -> Choose Symbol -> Your symbol`` and draw your circuit around it. That's it! ==Doesn't Work?== *Did you ''Create Viewpoint`` as described in [[IC studio]]? *Did you ''Set Simulation Models`` as described in [[IC studio]]? *Did you choose an "Analysis" (i.e. "Transient" or "DC") to be performed in simulation mode? *Do the node assignments correspond to the pin names on your symbol? *Some spice models you find on the web are written for PSPICE, HSPICE or some other SPICE language that might have syntax which is not supported by ELDO. Try to comment these out within the SPICE file, or replace them with similar syntax (see ELDO User's Manual). [[Category:Mikroelektronikk]] 5a87cbf0682ee72832be6c80b54363be1d089615 1830 1829 2013-02-15T11:46:59Z Tni071 73 wikitext text/x-wiki = Include a SPICE File in IC Studio = This is a description of how to download a spice file from the web and include it in your IC studio project. A symbol is created to represent the component described by the spice file, and the procedure of linking the spice file to your symbol is described (See the [[IC studio]] tutorial if you are new to symbols). The AD8000 opamp is used as an example throughout this tutorial. ==Download a SPICE File== Search the internet for a spice model, i.e. "AD8000 spice model". The vendor will normally provide such a file which can be downloaded. Open the file (ad8000p.cir) in a text editor and scroll down to the node assignments. The node assignments should match (identically) the pins of your soon to be created symbol. * Node assignments * non-inverting input * | inverting input * | | positive supply * | | | negative supply * | | | | output * | | | | | Power down * | | | | | | .SUBCKT AD8000 1 2 Vcc Vee Vout PD ==Create a Symbol== First you have to create a project library as explained in [[IC studio]]. In the cell view you should create a cell for your component which is of the view type "symbol". The next step is to start drawing your symbol with the desired shape and pins: Use the palette on the left side of the screen to draw lines, or use a predefined shape (i.e. a rectangle). From the same palette you can choose the "Add Pin" button. Choose the pin preferences as you find suitable, but note that the pin names must be identical to the node assignments in the spice file. Place your pins and create a nice symbol... ==Relate a SPICE File to a Symbol== Now you have a symbol, but it does not have any relation to the spice file except from the pin names. Right click on the cell you just made and add a new view of the type "spice". An almost blank spice file will pop up in the IC Studio text editor. Delete what is there and go to "file->insert file" and choose the spice file you have downloaded (you can also copy-paste the spice file) - save it. When you close the text editor, you will get a message: "Spice File Changed - Do you want to change the top sub-circuit"? Press yes and select the desired sub-circuit name. The following message should appear in IC Studio: // Starting Spice registration ... please wait // Note: Registering SPICE model "AD8000" with symbol "ad8000" // Note: Registration succeeded Create a new cell with your top-level circuit ("schematic" view). Now you can include the component by "Right-click -> Instance -> Choose Symbol -> Your symbol" and draw your circuit around it. That's it! ==Doesn't Work?== *Did you "Create Viewpoint" as described in [[IC studio]]? *Did you "Set Simulation Models" as described in [[IC studio]]? *Did you choose an "Analysis" (i.e. "Transient" or "DC") to be performed in simulation mode? *Do the node assignments correspond to the pin names on your symbol? *Some spice models you find on the web are written for PSPICE, HSPICE or some other SPICE language that might have syntax which is not supported by ELDO. Try to comment these out within the SPICE file, or replace with supported syntax (see ELDO User's Manual). [[Category:Mikroelektronikk]] f188c12a290f59cfa4693f284db37a1edaf432a1 0 414 1832 2013-02-15T11:52:49Z Tni071 73 SPICE Symbol tutorial added wikitext text/x-wiki = Include a SPICE File in IC Studio = This is a description of how to download a spice file from the web and include it in your IC studio project. A symbol is created to represent the component described by the spice file, and the procedure of linking the spice file to your symbol is described (See the [[IC studio]] tutorial if you are new to symbols). The AD8000 opamp is used as an example throughout this tutorial. ==Download a SPICE File== Search the internet for a spice model, i.e. "AD8000 spice model". The vendor will normally provide such a file which can be downloaded. Open the file (ad8000p.cir) in a text editor and scroll down to the node assignments. The node assignments should match (identically) the pins of your soon to be created symbol. * Node assignments * non-inverting input * | inverting input * | | positive supply * | | | negative supply * | | | | output * | | | | | Power down * | | | | | | .SUBCKT AD8000 1 2 Vcc Vee Vout PD ==Create a Symbol== First you have to create a project library as explained in [[IC studio]]. In the cell view you should create a cell for your component which is of the view type "symbol". The next step is to start drawing your symbol with the desired shape and pins: Use the palette on the left side of the screen to draw lines, or use a predefined shape (i.e. a rectangle). From the same palette you can choose the "Add Pin" button. Choose the pin preferences as you find suitable, but note that the pin names must be identical to the node assignments in the spice file. Place your pins and create a nice symbol... ==Relate a SPICE File to a Symbol== Now you have a symbol, but it does not have any relation to the spice file except from the pin names. Right click on the cell you just made and add a new view of the type "spice". An almost blank spice file will pop up in the IC Studio text editor. Delete what is there and go to "file->insert file" and choose the spice file you have downloaded (you can also copy-paste the spice file) - save it. When you close the text editor, you will get a message: "Spice File Changed - Do you want to change the top sub-circuit"? Press yes and select the desired sub-circuit name. The following message should appear in IC Studio: // Starting Spice registration ... please wait // Note: Registering SPICE model "AD8000" with symbol "ad8000" // Note: Registration succeeded Create a new cell with your top-level circuit ("schematic" view). Now you can include the component by "Right-click -> Instance -> Choose Symbol -> Your symbol" and draw your circuit around it. That's it! ==Doesn't Work?== *Did you "Create Viewpoint" as described in [[IC studio]]? *Did you "Set Simulation Models" as described in [[IC studio]]? *Did you choose an "Analysis" (i.e. "Transient" or "DC") to be performed in simulation mode? *Do the node assignments correspond to the pin names on your symbol? *Some spice models you find on the web are written for PSPICE, HSPICE or some other SPICE language that might have syntax which is not supported by ELDO. Try to comment these out within the SPICE file, or replace with supported syntax (see ELDO User's Manual). [[Category:Mikroelektronikk]] f188c12a290f59cfa4693f284db37a1edaf432a1 0 4 1834 1725 2013-05-21T11:56:36Z Stud4729 6 wikitext text/x-wiki == Overview == [[Image:RCU_DCS_sketch.png|thumb|500px|center|Sketch of the Readout Control Unit]] == DCS board firmware for TPC and PHOS == === Overview === [[Image:DCS_FW.png|thumb|350px|Schematic Overview of the DCS firmware for TPC/PHOS]] The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware. Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board * Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster. * Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed. * Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available. === Update of the DCS Board Flash Device === There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.<br><br> The ways of updating the boards are given at the DCS page of [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html Tobias Krawutschke]. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.<br><br> ====Updating the DCS boards:==== # Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer. <br> #: Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to ''4.1''. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.</li> # Using the tool remoteupdate4.sh<br> This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.</li> Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc... === Version history === '''1.0 (~april 2004)''' <br> <ul> <li> Made based upon TRD DCS FW version 011. </li> <li> Messagebuffer v1.0 (Torsten Alts orginal version)</li> <li> Virtex driver for programming RCU FPGA included </li> </ul> <br> '''2.0 (~may 2005)'''<br> <ul> <li> Updated Messagerbuffer</li> <ul> <li> new header format</li> </ul> </ul> <br> '''2.1 (12.12.2005)'''<br> <ul> <li> Updated messagebuffer:</li> <ul> <li> Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.</li> <li> compressing possible (2x16, 3x10, 4x8)</li> </ul> </ul> <br> '''2.2 (05.01.2006)'''<br> <ul> <li> Updated messagebuffer: </li> <ul> <li> Bugfix of reset state a state machine in rcu_master module</li> <li> Bugfix in configuration controller on checking the command/address on multiread</li> <li> Bugfix in configuration controller on multiwrite with compressing</li> <li> Fix in the compressing so that the way to count words matches the requirements.</li> <li> When compressing, writing/reading is switched from Big Endian to Little Endian.</li> <li> Included version, mode_select module and flash interface in messagebuffer module</li> <li> Made new set of commands for flash communication</li> <li> Synthesized using precission - using an edf file in Quartus.</li> <li> fw r also resets certain fw modules on the dcs board. </li> <li> Flash interface is reseted whenever flash mode is not selected.</li> </ul> <li>Updated ARM stripe</li> <ul> <li> Removed Direct PIO Flash interface</li> </ul> </ul> <br> Known issues in v2.2:<br> <ul> <li> Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.</li> </ul> <br> '''2.3 (27.02.2006)'''<br> <ul> <li>Updated messagebuffer: </li> <ul> <li> Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset </li> <li> Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00 </li> <li> Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5] </li> <li> ComStat register is made more robust using triple redundancy.</li> </ul> </ul> <br> '''2.4 (19.03.2006)''' <br> <ul> <li>RCU Communication Module:</li> <ul> <li> Memory size is made generic.</li> <li> Added tristate select input for selectmap mode.</li> <li> Increased timeout period of RCU mem mapped communication to 32 clks</li> <li> Increased length of WE and CE pulses of flash interface</li> <li> Changed tristate select for Flash interface </li> <li> Increased wait time for flash read</li> </ul> </ul> <br> '''2.5 (08.05.2006)'''<br> <ul> <li> VREG Module updated with new version from KIP</li> <li> Timing warnings removed with correct constraints settings</li> <li> Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.</li> <li> All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.</li> <li> output_enable_n is set by bit 4 in ComStat register </li> </ul> <br> '''2.6 (01.08.2006)'''<br> <ul> <li> RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)</li> <li> Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.</li> <li> Added Comstat(5) as DCS FW reset. </li> <li> Changed rcu_data(15) in Flash mode to input f_rynBy</li> <li> Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.</li> </ul> <br> '''2.61 Trigger-OR'''<br> <ul> <li> Pinning on DCS-RCU connector changed to match Trigger OR board. </li> <li> Added sm_enable register that is enabled by writing to 0xBF01.</li> <li> Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.</li> <li> SelectMAP interface can be accessed simultaneously as memory mapped interface. </ul> <br> '''2.62 BUSYBOX'''<br> <ul> <li> Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector</li> </ul> <br> Known issues in v2.6x:<br> <ul> <li> Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.</li> <li> Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.</li> </ul> As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.<br> <br> '''2.7 (03.08.2007)'''<br> <ul> <li> Ethernet Module upgraded to increase speed of Ethernet link as described [http://frodo.nt.fh-koeln.de/~tkrawuts/update_howto/ here]. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.</li> <li> Minor bugs mentioned in v2.6x corrected.</li> </ul> '''2.71 (12.09.2007) Trigger-OR'''<br> <ul> <li> Same as v2.61, but inlcuding the upgrades given in v2.7</li> </ul> '''2.72 (12.09.2007) BUSYBOX'''<br> <ul> <li> Same as v2.62, but inlcuding the upgrades given in v2.7</li> </ul> <br> '''2.8 (14.11.2007)'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:<ul> <li>"11"/"00" Memory mapped mode</li> <li>"01" Flash mode </li> <li>"10" Selectmap mode.</li></ul> The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot. <li> Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots</li> <li>added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness</li> <li> Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility. </ul> '''2.81 (30.11.2007) Trigger-OR'''<br> <ul> <li> Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.82 (30.11.2007) BUSYBOX'''<br> <ul> <li> Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)</li> </ul> '''2.83 (15.05.2008) BUSYBOX'''<br> <ul> <li> Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)</li> </ul> '''2.84 (08.10.2008) BUSYBOX'''<br> <ul> <li> Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)</li> </ul> '''2.9 (30.1.2012)'''<br> <ul> <li> Updated udhcpc <li> Updated rcS (udhcpc parameters, ntp timeserver, bootscript execution order) <li> modified nfsmount_all to only mount dcbrw and dcbro <li> added _S05restartreadback.sh, S27enable_ttcrx.sh, S31unsetOldMode.sh, S52startntp.sh to /etc/boot <li> removed S30rcu-conf.sh, S31setoldmode from /etc/boot <li> disabled CONFIG_DEBUG_SLAB in kernel </ul> <br> <br> === Download Section === Specification document:<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.6x.pdf RCU_comm_specification_v2.6x.pdf]<br> [http://web.ift.uib.no/firmware/alme/RCU_comm_specification_v2.8x.pdf RCU_comm_specification_v2.8x.pdf] <br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/messagebuffer/ SVN database] <br><br> <ul> <li>'''Version 2.2: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.2.bin armboot_v2.2.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.2.rar epxa1db_v2.2.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.2.rar Quartus Project] </li> <li>'''Version 2.3: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3.bin armboot_v2.3.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3.rar epxa1db_v2.3.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3.rar Quartus Project] </li> <li>'''Version 2.3 (SelectMap - special version to go with Gert Trögers SelectMap firmware/software): '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.3SelectMap.bin armboot_v2.3SelectMap.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.3SelectMap.sbi epxa1db_v2.3SelectMap.sbi] | [http://web.ift.uib.no/firmware/alme/xhwicapfpgafs.o xhwicapfpgafs.o] | [http://web.ift.uib.no/firmware/alme/xilinx_hwicap.o xilinx_hwicap.o] | [http://web.ift.uib.no/firmware/alme/loop.o loop.o] | [http://web.ift.uib.no/firmware/alme/readme.txt readme.txt] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.3_smap.rar Quartus Project] </li> <li>'''Version 2.4:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.4.bin armboot_v2.4.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.4.rar epxa1db_v2.4.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.4.rar Quartus Project] </li> <li>'''Version 2.5:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.5.bin armboot_v2.5.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.5.rar epxa1db_v2.5.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.5.rar Quartus Project] </li> <li>'''Version 2.6: '''<br> [http://web.ift.uib.no/firmware/alme/armboot_v2.6.bin armboot_v2.6.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.6.rar epxa1db_v2.6.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.6.rar Quartus Project] </li> <li>'''Version 2.61 Trigger-OR:''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.61.bin armboot_v2.61.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.61.sbi epxa1db_v2.61.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.61.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Trigger OR] </li> <li>'''Version 2.62 BUSYBOX: ''' <br> [http://web.ift.uib.no/firmware/alme/armboot_v2.62.bin armboot_v2.62.bin] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.62.sbi epxa1db_v2.62.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.62.rar Quartus Project] | [http://web.ift.uib.no/firmware/alme/virtex_driver.o virtexdriver kernel module] | [http://web.ift.uib.no/firmware/alme/rcS rcS file for Busy Logic] </li> <li>'''Version 2.7: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.7uib_dcs0031.hex hex file for dcs0031] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.7.rar epxa1db_v2.7.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.7.rar Quartus Project] </li> <li>'''Version 2.71 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.71uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.71.rar epxa1db_v2.71.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.71.rar Quartus Project] </li> <li>'''Version 2.72 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.72uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.72.rar epxa1db_v2.72.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.72.rar Quartus Project] </li> <li>'''Version 2.8: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.8uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/dcs_v2.8.zip kernel, armboot, updatescript for DCS upgrade] | [http://web.ift.uib.no/firmware/alme/Recipe_for_dcs_v2.8_actel_v1.4_upgrade.pdf Recipe for TPC DCS/Actel upgrade] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.8.rar epxa1db_v2.8.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_tpc_v2.8.rar Quartus Project] </li> <li>'''Version 2.81 Trigger-OR: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.81uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.81.rar epxa1db_v2.81.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_triggeror_v2.81.rar Quartus Project] </li> <li>'''Version 2.82 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.82uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.82.rar epxa1db_v2.82.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.82.rar Quartus Project] </li> <li>'''Version 2.83 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.83uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.83.rar epxa1db_v2.83.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.83.rar Quartus Project] </li> <li>'''Version 2.84 BUSYBOX: '''<br> [http://web.ift.uib.no/firmware/alme/dcsflash_boardrev164_firmware2.84uib_dcs0100.hex hex file for dcs0100] | [http://web.ift.uib.no/firmware/alme/epxa1db_v2.84.rar epxa1db_v2.84.sbi] | [http://web.ift.uib.no/firmware/alme/dcs1.52_busylogic_v2.84.qar Quartus Project (Archive)] </li> <li>'''Version 2.9: '''<br> [http://web.ift.uib.no/~dominik/files/dcs_fw/dcsflash_boardrev164_firmware2.9uib_dcs0031.hex hex file for dcs0031] | [[Firmware files for boards 30 - 1400]] | [http://web.ift.uib.no/~dominik/files/dcs_fw/rcS rcS file for new udhcpc, boot script order] </li> <br> </ul> ''Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/remoteupdate4.sh remoteupdate4.sh] script in the following way:'' <br> ./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel<br> ''For detailed instuctions on using the remotesetup look [http://frodo.nt.fh-koeln.de/~tkrawuts/firmware/index.html here]. ''<br><br> ''When using remotesetup one should also upgrade:'' <ul> <li> ''The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.''</li> <li> ''The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:'' <ul> <li>''Kernel:'' md5sum /dev/mtd/2</li> <li>''Armboot:'' md5sum /dev/mtd/0</li> </ul> </ul> <br><br> Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions. <br><br> The bin file can be used directly to change the firmware of the board. This can be done in the following way:<br> <ol> <li> Log onto DCS board. <li> Remove old firmware: eraseall /dev/mtd/0 <li> Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0 <li> Reboot board </ol> The firmware version is reported when starting the rcu-sh.<br><br> The sbi-file is used when building the complete DCS project. This should only be used by experts. <br><br> The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported. <br><br> == DCS board Lattice CPLD-firmware for TPC and PHOS == === Overview === The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br> To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br> To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br> === Download Section === Complete Project: [http://web.ift.uib.no/firmware/alme/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br> Programming File: [http://web.ift.uib.no/firmware/alme/vreg.jed vreg.jed]<br> ispVM System Project File: [http://web.ift.uib.no/firmware/alme/vreg.xcf vreg.xcf]<br><br> == RCU Trigger Receiver Module == === Overview === [[Image:TTC_Receiver_schematic_v1-1_final.png|thumb|350px|Sketch of RCU Trigger Receiver v1.1]] Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.<br><br> The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost. <br><br> To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).<br><br> In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted. <br><br> To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.<br><br> === Version === '''v1.0'''<br> <ul> <li> Decoding serial B input</li> <ul> <li> Broadcast messages</li> <li> Individual addressed messages</li> </ul> <li> Hamming decoding of serial B message</li> <ul> <li> Repair and count single bit errors</li> <li> Count other errors</li> </ul> <li> Generation of Level 2 accept, Level 2 reject and RoI trigger</li> <li> Generation of eventcount reset and bunchcount reset from serial B broadcast messages.</li> <li> Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.</li> <li> Verification if L2a+L2r = L1a</li> <li> Testmode that simulates arrival of serial B messages.</li> <li> Handling of transmission errors etc.</li> <li> Memory mapped interface.</li> <li> Trigger info outputs for data assembler</li> </ul> <br> '''v1.1'''<br> <ul> <li>Redesigned most parts of the module.</li> <li>Supports both RCU and Trigger Busy Logic Board.</li> <li>Decoding serial B input</li> <ul> <li>Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)</li> <li>Individual addressed messages (L1a, RoI, L2a, L2r)</li> </ul> <li>Decode L1a line to L0 trigger and L1a trigger.</li> <li>Hamming decoding of serial B message.</li> <li>Report, repair and count single bit hamming errors</li> <li>Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors</li> <li>Generation of L0, L1a, L2a and L2r trigger</li> <li>Decoding of RoI is optional and can be enabled in the Control/Status register</li> <li>Status output showing if run is ongoing. (Between vanguard and rearguard trigger.) </li> <li>Counters: Internal bunchcounter, trigger counters, message counters and error counters.</li> <li>Reporting transmission errors etc</li> <li>Reporting timeouts and sequence errors.</li> <li>Memory mapped interface.</li> <ul> <li> RCU Version with 32 bit bidir data-bus.</li> <li> Trigger Busy Logic Version with 16 bit bidir data-bus.</li> </ul> <li>FIFO with header words and event information for data assembly</li> <li>Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.</li> </ul> <br> '''v1.2 (13.12.2007)'''<br> <ul> <li>Sample serial B and L1 accept line on falling edge.</li> <li>Remake of L1a decode module to simplify it.</li> <li>Remake of Adressed message decoder: <ul> <li>Added FEE reset decoding</li> <li>It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)</li> </ul></li> <li>Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier</li> <li>Some modoifications to the Error and infor register</li> <li>Added Phase check module to store in what phase of the sampling clock the trigger arrives</li> <li>Control registers slighlt changed</li> <li>All latencies now given with respect to L0 trigger instead of BC0</li> </ul> <br> '''v 1.21 (29.05.2008)'''<br> <ul> <li>Corrected the version information in the CDH.</li> <li>Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives</li> </ul> <br> '''v 1.22 (30.05.2008)'''<br> <ul> <li>Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.</li> </ul> <br> '''v 1.23 (12.06.2008)'''<br> <ul> <li>Removed input meb_depth and a meb_mask_enable to control register. </li> <li>Removed test for RoC = 0 when physics trigger as this was not correct</li> <li>Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events</li> </ul> <br> '''v 1.24 (13.01.2009)'''<br> <ul> <li>Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.<br> This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).</li> </ul> <br> '''v 1.3 (11.02.2009)'''<br> <ul> <li>Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message. </li> <li>Removed ROI decoding (only commented out) because of area constraints on RCU.</li> <li>Added version number in control/status register</li> </ul> <br> '''v 1.4 (24.03.2010)'''<br> <ul> <li>Minor change to sequence validator only. CIT bit is no longer verified against arrival of pre-pulse. (Specified in mail correspondance with Terry Awes 23.03.2010). </li> </ul> <br> '''v 1.5 (17.08.2010)'''<br> <ul> <li>Fix done by Attiq Ur Rehman:<br> There is minor change in the "fifo wrapper":<br> Line #73 new signal cnt_dn<br> Line #91 comparison with "read_counter"<br> Line #170,172,174 check of possible logical conditions<br> This file was used for the RCU firmware (from 10th July and on wards) to fix the Erroneous behavior causing busy condition. </li> </ul> <br> '''v 1.6 (20.01.2012)'''<br> <ul> <li>Single l2 messages does not generate CDH</li> <li>Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register.</li> <li>Cleaned up code and removed commented lines (RoI is now gone)</li> <li>Minor changes to DAQ header error word</li> <li>New output: sync - software trigger decoded from RoC = 0xD</li> </ul> <br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/TTC_receiver_specification_v1-0.pdf Preliminary documentation for Firmware version 1.0] <br> [http://web.ift.uib.no/firmware/alme/RCU_trigger_receiver_v1-0.zip Firmware v 1.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-0.zip Xilinx Project used for test - Firmware v 1.0]<br> [http://web.ift.uib.no/firmware/alme/TTC_receiver_v1-0.bit Xilinx xc2vp7 programming file - Firmware v 1.0]<br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.1.pdf Specification/design document for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1_source_files.rar Firmware v 1.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.1-scripts.rar Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-1.rar Xilinx Project used for test - Firmware v 1.1]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.1.bit Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)]<br><br> ''Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.<br> The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits<br> - Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.<br> - Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.'' <br><br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.2_updated.pdf Specification/design document for Firmware version 1.2] (Updated 13.05.08) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.2_source_files.rar Firmware v 1.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/Xilinx_project_v1-2.rar Xilinx Project used for test - Firmware v 1.2]<br> [http://web.ift.uib.no/firmware/alme/rcu_trigger_reveiver_v1.2.bit Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)]<br><br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.21_source_files.rar Firmware v 1.21 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.22.pdf Specification/design document for Firmware version 1.22] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.22_source_files.rar Firmware v 1.22 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.23.pdf Specification/design document for Firmware version 1.23] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.23_source_files.rar Firmware v 1.23 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.24_source_files.rar Firmware v 1.24 - Only updated sequence validator]. <i>Download version 1.23 and replace sequence_validator with this file.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.3.pdf Specification/design document for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.3_source_files.rar Firmware v 1.3 - VHDL files, including testbench]<br> <br> [http://web.ift.uib.no/firmware/alme/sequence_validator2010-03-24.rar Firmware v 1.4 - sequence_validator.vhd and trigger_receiver_pkg.vhd]. <i>Download version 1.3 and replace the two files.</i> <br> <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.5_source_files.rar Firmware v 1.5 - VHDL files, including testbench]<br> <br> <br> <br> [http://web.ift.uib.no/firmware/alme/Trigger_receiver_requirement_specification_v1.6.pdf Specification/design document for Firmware version 1.6] (Updated 20.01.12) <br> [http://web.ift.uib.no/firmware/alme/trigger_receiver_v1.6_source_files.zip Firmware v 1.6 - VHDL files, including testbench]<br> <br> All source files and more can be downloaded from the [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/trigger_receiver/ SVN database]. <br><br> == RCU DCS Interface Module == === Overview === [[Image:dcs_interface_v0.2.png|thumb|350px|Sketch of RCU DCS Interface v0.2]]The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.<br><br> One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device. <br><br> Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this. <br><br> === Version === '''v0.1'''<br> <ul><li>First proper version of DCS interface supporting all features given in overview.</li></ul> <br> '''v0.2'''<br> <ul><li>Adapted to match new mode settings of dcs fw v2.8. </li></ul> <br> '''v0.3 (12.02.08)'''<br> <ul> <li>Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins. </li> <li>Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)</li> <li>Changed the register adresses for the grant and interrupt</li> <li>Added we for msm module and separate data input from msm module</li> </ul> <br> === Download Section === [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.2.pdf Specification/design document for Firmware version 0.2] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.2.rar Firmware v 0.2 - VHDL files, including testbench]<br><br> [http://web.ift.uib.no/firmware/alme/dcs_interface_specification_v0.3.pdf Specification/design document for Firmware version 0.3] <br> [http://web.ift.uib.no/firmware/alme/dcs_interface_v0.3.rar Firmware v 0.3 - VHDL files, including testbench]<br><br> == PHOS FEC Board Controller == === Overview === [[Image:PHOS_BC_v3.3.png|thumb|350px|Sketch of PHOS FEC Board Controller v3.3]] The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur. <br><br> The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC. <br><br> The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage. <br><br> This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust. <br><br> === Version === '''v3.0 (16.08.2007)'''<br> <ul> <li>Functionally based on PHOS PCM v2.0 (hence the version number)</li> <li>Two command interfaces <ul> <li>ALTRO bus interface <li>Special I2C interface</li> </ul></li> <li>Setting of DACs for bias voltage for High Voltage region</li> <li>Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.</li> <li>Programmable thresholds for flagging errors in ADC values.</li> <li>Monitoring error inputs from Power Regulators</li> <li>Interrupt line to RCU for errors of a severity level craving urgent measures</li> <li>Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.</li> <li>Radiation environment precautions: <ul> <li>Hamming coded ADC threshold settings</li> <li>Hamming coded DAC values</li> <li>TMR of configuration/status register</li> </ul></li> <li>Configurable automatic update of DAC</li> <li> Thresholds, ADC values and DAC values stored in memories.</li> </ul> <br> Functional changes from HUST PCM v2.x <ul> <li>Removal of USB communication</li> <li>Removal of Board ID register</li> <li>Hamming encoding and TMR of static registers/memories.</li> <li>Some register remapping.</li> <li>Thresholds and ADC values stored in memories</li> </ul> <br> '''v3.1 (11.09.2007)'''<br> <ul> <li>Added high and low ADC threshold memory</li> <li>Added new module for verifying ADC values</li> <li>Remapped registers.</li> <li>Configurable number of times (1-3) of same threshold error before interrupt is flagged</li> <li>Added two registers to decide if adc values will be treated as current or voltages.</li> <li>Continously reading ADC not default on.</li> <li>Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)</li> <li>Added an unlock register to make it possible to overwrite certain status registers for debug purposes</li> <li>Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).</li> <li>Bugfix of DAC interface in case of hamming error in last channel of each dac</li> </ul> <br> '''v3.2 (03.10.2007)'''<br> <ul> <li>Problem with Slow Control Communication attemped solved by making the slave more robust: <ul> <li>The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.</li> <li>Added timeout counters for Slow Control Transactor and Receiver</li> <li>Rewrote state machine in I2C Slave to reduce the amount of combinatorics.</li> <li>Added sda_out line to csr 3 register for debug</li> </ul></li> <li>Rewrote state machines in ADC interface to reduce the amount of combinatorics.</li> </ul> <br> '''v3.3 (17.10.2007)'''<br> <ul> <li>Included support for Sparse Readout: <ul> <li>Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).</li> <li>Hitmap transmitted by the use of dstb that is a gated version of the readout clock.</li> <li>Added the needed functionality on the driver module to support the BC being ALTRO bus master.</li> <li>Added the needed registers adresses for Sparse Readout. Exact copy of TPC version</li> <li>Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment</li> </ul></li> <li>Rewrote ALTRO interface to one single module with the aim of making it more robust.</li> <li>Minor change in driver to make ppr simulation possible</li> <li>Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map</li> <li>Added a debug register with information on the state of the sda line and test_mg input. </li> </ul> <br> '''v3.4 (31.10.2007)'''<br> <ul> <li>Added debug counters and registers in the ALTRO interface module: <ul> <li>Counters for number of received strobes, and number of generated acks.</li> <li>Information stored concerning the last acked address, and last address not acked.</li> </ul> </li> <li>Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.</li> </ul> ''The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.'' <br><br> '''v3.5 (30.03.2008)'''<br> <ul> <li>Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers</li> <li>Changed start condition of the readout command detect state machine to make it behave better in ppr simulations</li> <li>Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)</li> </ul> <br><br> '''v3.6 (21.05.2013)'''<br> <ul> <li>Redesign of the Slow Control interface. SCLK frequency should be 2.5 MHz (RCU reg 0x800C = 0x1). </li> <li>Bugfix of Sparse Readout. Added Debug functionality for low level test of Sparse readout.</li> </ul> === Download Section === [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_specification.pdf Specification/design documentation for Firmware version 3.0] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_source.rar Firmware v 3.0 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_Quartus_project.rar Quartus Project - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_programming_files.rar Programming files - Firmware v 3.0]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.0_scripts.rar Scripts used for testing - Firmware v 3.0]<br> ''Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.'' <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_specification.pdf Specification/design documentation for Firmware version 3.1] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_source.rar Firmware v 3.1 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_Quartus_project.rar Quartus Project - Firmware v 3.1]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.1_programming_files.rar Programming files - Firmware v 3.1]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_specification.pdf Specification/design documentation for Firmware version 3.2] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_source.rar Firmware v 3.2 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_Quartus_project.rar Quartus Project - Firmware v 3.2]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.2_programming_files.rar Programming files - Firmware v 3.2]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_specification.pdf Specification/design documentation for Firmware version 3.3] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_source.rar Firmware v 3.3 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_Quartus_project.rar Quartus Project - Firmware v 3.3]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.3_programming_files.rar Programming files - Firmware v 3.3]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_specification.pdf Specification/design documentation for Firmware version 3.4] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_source.rar Firmware v 3.4 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_Quartus_project.rar Quartus Project - Firmware v 3.4]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.4_programming_files.rar Programming files - Firmware v 3.4]<br> <br><br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_specification.pdf Specification/design documentation for Firmware version 3.5] <br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_source.rar Firmware v 3.5 - VHDL files, including testbench]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_Quartus_project.rar Quartus Project - Firmware v 3.5]<br> [http://web.ift.uib.no/firmware/alme/phos_bc_v3.5_programming_files.rar Programming files - Firmware v 3.5]<br> <br><br> [http://web.ift.uib.no/~alme/wiki/phos_bc_v3.6_specification.pdf Specification/design documentation for Firmware version 3.6] <br> [http://web.ift.uib.no/~alme/wiki/phos_bc_v3.6_source.zip Firmware v 3.6 - VHDL files, including testbench]<br> [http://web.ift.uib.no/~alme/wiki/phos_bc_v3.6_Quartus_project.zip Quartus Project - Firmware v 3.6]<br> [http://web.ift.uib.no/~alme/wiki/phos_bc_v3.6_programming_files.zip Programming files - Firmware v 3.6]<br> <br> [http://web.ift.uib.no/~alme/wiki/phos_bc_v3.6_programming_user_guide.pdf Programming User Guise for Firmware version 3.6] <br> [http://web.ift.uib.no/~alme/wiki/12.0_178_programmer_windows.exe Altera Programmer v12.0] <br> [http://web.ift.uib.no/~alme/wiki/ug_usb_blstr.pdf Altera USB Blaster User Guide]<br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/phos_bc/ SVN database] <br> <br> == RCU Auxilliary FPGA Firmware for TPC and PHOS == === Overview === [[Image:actel_fw1-3.png|thumb|350px|Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4]] Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain. <br><br> To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable. <br><br> === Updating the Actel Firmware === [[Image:FlashProLite.jpg|thumb|left|200px|Actel FlashPro Lite]] The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the [http://www.actel.com/custsup/updates/flashpro/index.html flashpro software tool]. Note that version 9.0 gives errors when trying to program the FPGA. [ftp://ftp.actel.com/downloads/flashpro/FlashPro86.zip Version 8.6] is the last version that works for the Actel on the RCU.<br> Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register. <br><br><br><br><br> === Updating The RCU Flash Device === When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.<br> <br> To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)<br><br> The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: [http://ep-ed-alice-tpc.web.cern.ch/ep-ed-alice-tpc/firmware.htm CERN EP-ED ALICE TPC]. <br><br> Be aware of the following <ul> <li>There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:<br> <i> rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash<br> rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx</i></li> <li>If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.</li> <li>Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.</li> <br> === Version History === '''v1.0'''<br> <ul> <li>Working revision of rcu CPLD firmware.</li> <li>supported in mem mapped mode:</li> <ul> <li> read flash</li> <li> write flash</li> <li> erase complete flash</li> <li> erase sector</li> <li> verify flash</li> <li> init configuration</li> </ul> <li> direct selctmap mode tested and verified</li> <li>direct flash mode not tested.</li> </ul> <br> '''v1.1'''<br> <ul> <li> Bug fix in direct flash mode - tested and verified working</li> <li> Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)</li> <li> Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process</li> <li> Read of Xilinx selectmap interface is verified working using Mem mapped interface. </li> <li> Verify Flash method removed</li> <li> Status register updated with more status/error information. </li> <li> If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)</li> <li> Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.</li> <li> Added continously scrubbing and abort command.</li> </ul><br> Known issues in v1.1:<br> <ul> <li> After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU. </li> </ul> <br> '''v1.2'''<br> <ul> <li> Made both DCS control over Flash interface and Selectmap interface generic.</li> <li> Init config supported</li> <li> Scrubbing of complete configuration supported </li> <ul> <li> single</li> <li> continous until abort</li> <li> continous # number of cycles</li> </ul> <li> Readback frame by frame verification and correcting supported</li> <ul> <li> Single step. One frame at the time</li> <li> Continous until abort. Runs complete cycles.</li> <li> Continous # number of times. Runs complete cycles.</li> </ul> <li> Counters for Number of Readback Verification errors and number of cycles added.</li> <li> Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)</li> <li> Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)</li> <li> Status register re-arranged</li> <li> Error register added</li> <li> Command register re-arranged</li> <ul> <li> Clear error and clear status added.</li> <li> Added Selectmap Command register</li> <li> Added Flash Command register</li> </ul> <li> Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.</li> <li> Removed delay when in between scrub cycles</li> </ul><br> Known issues v1.2:<br> <ul> <li> The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.</li> <li> Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).</li> <li> Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.</li> </ul> <br> '''v1.3'''<br> <ul> <li> Fixed critical timing issues when doing frame by frame read-back verification</li> <ul> <li> Cleaned up state machine in Configuration Controller module</li> <li> Added look up tables and pipelined the readback error counter</li> <li> Synchronized the input control lines for the selectmap bus.</li> <li> Relaxed the timing on the selectmap interface</li> <li> A bit slower operation – but timing is now good.</li> </ul> <li> Removed register for reading the last address being written to.</li> <li> Changed reset register to 0xb003</li> <li> Fixed a bug when clearing error register</li> <li> Set continuous scrubbing to read pointer between scrub cycles to refresh registers.</li> <li> The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.</li> <li> Added power up detection module that start initial configuration</li> <li> Added stop code register for stopping power up detection module from trying to reconfigure. </li> <li> Added address generator module to save area.</li> <li> Added new generic variable to select type of flash device (BB or BT)</li> <li> Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)</li> <li> Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues. </li> <li> Added f_rynby line to DCS board in direct Flash mode</li> <li> Added output seu_error on dcs_ctrl3 in normal operation mode.</li> </ul><br> Known issues in v1.3:<br> <ul> <li> The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.</li> <li> When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).</li> </ul> <br> '''v1.4'''<br> <ul> <li>Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to: <ul> <li>"11"/"00" Memory mapped mode </li> <li>"01" Flash mode</li> <li>"10" Selectmap mode.</li> </ul> The most important is that memory mapped mode is now "11". This is default state of these lines when the DCS board do not drive the lines during reboot.</li> <li>The SEU_error flag is inverted so that default state is high. </li> <li>Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.</li> <li>Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.</li> </ul> <br><br> === DCS Software Tools for operating the Actel === Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks: <br> <ol> <li> '''framegen''' - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).</li> <li> '''framever''' - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.</li> <li> '''rcuflashprog''' - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.</li> </ol><br> Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.<br><br> More information on how to use frame by frame reconfiguration to be added. <br><br> Updates of these tools will come in the near future.<br><br> === Download Section === [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-1.pdf Preliminary documentation for Firmware version 1.1] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-1.stp Firmware v 1.1 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-2.pdf Preliminary documentation for Firmware version 1.2] <br> [http://web.ift.uib.no/firmware/alme/actel_v1-2.stp Firmware v 1.2 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-3.pdf Preliminary documentation for Firmware version 1.3]<i>(Updated 8. Nov 2006)</i><br> [http://web.ift.uib.no/firmware/alme/actel_v1-3.stp Firmware v 1.3 programming file] <br><br> [http://web.ift.uib.no/firmware/alme/Actel_usermanual_v1-3.pdf User manual for Firmware version 1.3 (and 1.4)] <br> [http://web.ift.uib.no/firmware/alme/Actel_specification_v1-4.pdf Preliminary documentation for Firmware version 1.4]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4_testplan.pdf Functional Test report for Firmware version 1.4 (also included in the documentation)]<br> [http://web.ift.uib.no/firmware/alme/actel_v1-4.stp Firmware v 1.4 programming file] <br><br> Source files: [http://web.ift.uib.no/kjekscgi-bin/viewvc.cgi/alice-fw/trunk/rcu_cpld/ CVS database] <br><br> For assosiated information concerning software and software tool download section, go to: [[The Actel software device in the FeeServer CE]] [[Category:Alice]] [[Category:Mikroelektronikk]] 78222b1944325e6043dcaef0f9a39e37bc9802e5 0 203 1835 1792 2013-05-27T08:46:40Z Ave082 33 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23, 28 or 57 to Blandonnet, and then change to the tram 18 "CERN" or Y "Val-Thoiry". Check [http://www.tpg.ch tpg.ch] for the timetable. To get to the bus you go left and into the area leading to the trains. Take the escalator to the second floor and the bus stop is right outside. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. *CERN account. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 3f42195a1e9fdc0b5dc7bec3d17298acdc398a03 0 279 1836 1139 2013-05-28T16:18:26Z Ave082 33 wikitext text/x-wiki [[SSH innlogging]] Hvordan logge inn med ssh fra remote Windows-PC [[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[Xming]] Hvordan bruke Xming for å logge inn fra remote Windows-PC [[http://www.msc.rl.ac.uk/europractice/software/mentor.html Europractice Mentor Graphics Software Overview]] [[http://www.msc.rl.ac.uk/europractice/software/cadence.html Europractice Cadence Software Overview]] [[Cadence]] Hvordan installere Cadence [[Category:Mikroelektronikk]] 28b9c46db1b0ccec12eb5eeba1711c2a828e116e 0 415 1837 2013-05-28T16:32:30Z Ave082 33 Created page with " == update install manager == cd /prog/cadence/ * mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install mana..." wikitext text/x-wiki == update install manager == cd /prog/cadence/ * mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh 4ad78d838bb50f3ede35272bad4b5836e4de3133 1838 1837 2013-05-28T16:59:18Z Ave082 33 wikitext text/x-wiki == update install manager == cd /prog/cadence/ * mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh == configure install manager == preferences -> directories Set default install directory to /prog/cadence == install/update program with install manager == Press the icon which has the text "local directory/media install" Select browse and navigate to the directory containing the install files and select the CDROM1 foleder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == -- INCISIVE -- When doing a full install, INCISIVE needs to be installed first as it is required by IC. -- ASSURA -- There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. 28bba9af9524e12cc64f12fea14534e52ab1b5dd 1839 1838 2013-05-29T13:55:43Z Ave082 33 wikitext text/x-wiki == update install manager == cd /prog/cadence/ * mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories Set default install directory to /prog/cadence == install/update program with install manager == Press the icon which has the text "local directory/media install" Select browse and navigate to the directory containing the install files and select the CDROM1 foleder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. Select the correct path to install to, keep the existing naming convention. If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. If a window opens which asks about configuring the license server, press n. When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == -- INCISIVE -- When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. -- ASSURA -- There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. -- ALTOS -- Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. 9d47227df8e5f18ca37157db0bf1951d387976ed 1840 1839 2013-06-06T12:50:55Z Ave082 33 wikitext text/x-wiki == update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ * mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories Set default install directory to /prog/cadence == install/update program with install manager == For new installs, follow the install Press the icon which has the text "local directory/media install" Select browse and navigate to the directory containing the install files and select the CDROM1 foleder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. Select the correct path to install to, keep the existing naming convention. If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. If a window opens which asks about configuring the license server, press n. When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification be5243616df37aed82871b859d70e4c1715b2efc 1863 1840 2013-07-19T08:24:26Z Ave082 33 wikitext text/x-wiki For complete system install please follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. == update install manager == Always update install manager if a newer exists or else installations may fail. <source> cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION </source> == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories Set default install directory to /prog/cadence == install/update program with install manager == For new installs, follow the install Press the icon which has the text "local directory/media install" Select browse and navigate to the directory containing the install files and select the CDROM1 foleder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. Select the correct path to install to, keep the existing naming convention. If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. If a window opens which asks about configuring the license server, press n. When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification 0873d3e874b0b0a6d2b5a3896717ae337b6de3be 1864 1863 2013-07-19T08:29:37Z Ave082 33 wikitext text/x-wiki For complete system install please follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. == update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories Set default install directory to /prog/cadence == install/update program with install manager == For new installs, follow the install Press the icon which has the text "local directory/media install" Select browse and navigate to the directory containing the install files and select the CDROM1 foleder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. Select the correct path to install to, keep the existing naming convention. If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. If a window opens which asks about configuring the license server, press n. When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification d211c84489f3f14b93f86dc03e797f2eb184c60f 1865 1864 2013-07-19T08:31:58Z Ave082 33 wikitext text/x-wiki For complete system install please follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. == update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install Press the icon which has the text "local directory/media install" Select browse and navigate to the directory containing the install files and select the CDROM1 foleder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. Select the correct path to install to, keep the existing naming convention. If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. If a window opens which asks about configuring the license server, press n. When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification 99d5c86db51154e0181896a3f6424f960016de93 1867 1865 2013-07-19T08:37:05Z Ave082 33 wikitext text/x-wiki == update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. :Press the icon which has the text "local directory/media install" :Select browse and navigate to the directory containing the install files and select the CDROM1 folder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 :You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. Select the correct path to install to, keep the existing naming convention. If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. If a window opens which asks about configuring the license server, press n. When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification f34161fd4710707b8b3b2285df72a0822aca3ebe 1868 1867 2013-07-19T08:41:33Z Ave082 33 wikitext text/x-wiki == update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. Check that there isn't a slash at the end of the path. Program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification 7398cf7ab4c1da48a445e956b216a886c2f5cc0d 1869 1868 2013-07-19T08:45:17Z Ave082 33 wikitext text/x-wiki == update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification 636844a7ed01b78011feb88646f4a996a1dd0f65 1870 1869 2013-07-19T10:43:51Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 *Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh 6374dd2aae01bceeaf530e01e61bb51f349b2e47 1871 1870 2013-07-19T13:53:23Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh == Scripts == ===Checksys.sh== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt #read -p "Press enter to continue" fi done done </script> 9e6d666aad34425a23fab3109a09bc981748133c 1872 1871 2013-07-19T13:55:53Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh == Scripts == ===Checksys.sh== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> 1cb1e3e2cfdfa486207efdae5cb09197c3af6d85 0 416 1842 2013-06-12T16:17:45Z Ave082 33 Created page with "=Download= Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN =Get a free 1 year license= Goto: http://www.actel.com/Portal/DPortal.aspx and c..." wikitext text/x-wiki =Download= Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN =Get a free 1 year license= Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ==Find out your Disk Serial Number.= Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. =Install= Start LiberoSoCv11 - Select Install Libero SoC (not the SA) - Select to install ALL - Synplify Pro - SoftConsole - Synphony - Identify - ModelSim - Fusion - Igloo, Igloo nano - Igloo Plus - Iglooe - ProAsic3 - ProAsic3E - ProAsic3L - SmartFusion - SmartFusion2 Apply and install license if you not already have a license installed. 4eb7a4204ddac6ee8b44fcbda76bec24acbae1a2 1843 1842 2013-06-12T16:18:32Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ==Find out your Disk Serial Number== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. ==Install== Start LiberoSoCv11 - Select Install Libero SoC (not the SA) - Select to install ALL - Synplify Pro - SoftConsole - Synphony - Identify - ModelSim - Fusion - Igloo, Igloo nano - Igloo Plus - Iglooe - ProAsic3 - ProAsic3E - ProAsic3L - SmartFusion - SmartFusion2 Apply and install license if you not already have a license installed. 1bbf814d9787e13e725b253be62c956f74561b08 1844 1843 2013-06-12T16:19:04Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ==Find out your Disk Serial Number== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL - Synplify Pro - SoftConsole - Synphony - Identify - ModelSim - Fusion - Igloo, Igloo nano - Igloo Plus - Iglooe - ProAsic3 - ProAsic3E - ProAsic3L - SmartFusion - SmartFusion2 Apply and install license if you not already have a license installed. 0279d3cc22ac1ab8ddab7d4660b4ae7152c47367 1845 1844 2013-06-12T16:19:26Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ==Find out your Disk Serial Number== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro - SoftConsole - Synphony - Identify - ModelSim - Fusion - Igloo, Igloo nano - Igloo Plus - Iglooe - ProAsic3 - ProAsic3E - ProAsic3L - SmartFusion - SmartFusion2 Apply and install license if you not already have a license installed. 8b1fa154a54f98b8fab26ecc67f84f373cb6b2e1 1846 1845 2013-06-12T16:20:43Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ==Find out your Disk Serial Number== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. b50d21df8fa37fc1e476adc6ea8804d670189c9a 1847 1846 2013-06-12T16:22:13Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ==Find out your Disk Serial Number== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. daf536fe57c7c918a66e60db3e5331235469c235 1848 1847 2013-06-12T16:22:29Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. 55e58e230e178020bc2a7665f6ba410f6c9a99c6 1849 1848 2013-06-12T16:22:59Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. 3c748541a38071714a971062badc3bbff5a867fb 1850 1849 2013-06-12T16:25:23Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. 9c9f2994be3724dea5661dd838dcef3b139f8bee 1851 1850 2013-06-13T08:55:34Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 1: SF2 USB== 2653bec7667cc9e7e9cb0c40b7f96490898464f9 1852 1851 2013-06-13T08:59:30Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Add tips or corrections for tutorials below. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 1: SF2 USB== bdff98810928c6cac3b9b7ca49d561d68483160e 1853 1852 2013-06-13T09:14:37Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Add tips or corrections for tutorials below. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == If you forget to check the box marked "Monitor FPGA fabric PLL Lock" in step 2 point 13 the output data from the SF2 over RS232 data will be garbled. ==Tutorial 1: SF2 USB== 6d40e040a724416b8576fa5a148a396104c345ef 1854 1853 2013-06-13T09:16:58Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. Add tips or corrections for tutorials below. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == If you forget to check the box marked "Monitor FPGA fabric PLL Lock" in step 2 point 13 the output data from the SF2 over RS232 data will be garbled. ==Tutorial 1: SF2 USB== 5368bc197bbf9d470b38a6b14226360cdcc67cab 1855 1854 2013-06-13T09:17:37Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == If you forget to check the box marked "Monitor FPGA fabric PLL Lock" in step 2 point 13 the output data from the SF2 over RS232 data will be garbled. ==Tutorial 1: SF2 USB== 4f30b1bb6753d1b578a9b530150433796f72c01b 1856 1855 2013-06-13T09:24:21Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == [[Media:Cortex_M3_lab_guide_v1.1_AV.docx|DOC]] If you forget to check the box marked "Monitor FPGA fabric PLL Lock" in step 2 point 13 the output data from the SF2 over RS232 data will be garbled. ==Tutorial 1: SF2 USB== 12a98a34d3504c0763bf6bbe195f49e4961bb953 1857 1856 2013-06-13T09:27:30Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== [[Media:Fabric_lab_guide_v1.1_AV.docx|Tutorial 1]] ==Tutorial 2: SF2 ARM Cortex-M3 == [[Media:Cortex_M3_lab_guide_v1.1_AV.docx|Tutorial 2]] If you forget to check the box marked "Monitor FPGA fabric PLL Lock" in step 2 point 13 the output data from the SF2 over RS232 data will be garbled. ==Tutorial 1: SF2 USB== [[Media:USB_lab_guide_v1.1_AV.docx|Tutorial 3]] 6ae3e0764195bc9979750a0fef0be89d1e030bf0 1858 1857 2013-06-13T12:50:22Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver2 in the folder Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. ef28ab627267b469e9a5013becae50e17eb039f3 1859 1858 2013-06-13T13:40:27Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. a2bf4bd368a2c0c67650be5ffb0507fcdbe6ac98 1860 1859 2013-06-27T09:00:34Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= Rightclick in the library pan of Questasim and choose new->Library. Choose "A map to an existing library". Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. 0a9549cfe0ed706724a93ab2adf4d94b3dde9623 1861 1860 2013-06-27T09:01:17Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= * Rightclick in the library pan of Questasim and choose new->Library. * Choose "A map to an existing library". * Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. f8785c7c4c4c048df4a47ecc4c2ce88a0d8d8368 1862 1861 2013-06-27T09:03:35Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= * Rightclick in the library pan of Questasim and choose new->Library. * Choose "A map to an existing library". * Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. * Include the library in the files where you need SF2 cores The same applies for other actel devices. e8b9700e311a4e52ccfedc4b3453396a64a0ccdf 10 417 1866 2013-07-19T08:32:46Z Ave082 33 Created page with "<br style="clear:both;" />" wikitext text/x-wiki <br style="clear:both;" /> c9baeab206eda22ea64542e99a8f6e2258903c2a 0 415 1873 1872 2013-07-19T13:56:14Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> 08d5316263eac2bbc75f7a5996a7f5779e6515ae 1874 1873 2013-07-19T14:17:22Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> 0e115c55045af00aac846a9a180eb08ec749a774 1875 1874 2013-07-19T14:18:15Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> 8e45b82022dda30d02a77d81fa8c955d724a504b 1876 1875 2013-07-19T14:59:16Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </scipt> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <script lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </script> Then check the version in the aformentioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> ea4bec51b405035a16c6739465e8a0e603c98e72 1877 1876 2013-07-19T14:59:53Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </script> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <script lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </script> Then check the version in the aformentioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> ef46ab762ea0c2d826a3841f9c58f771b1b0d4f1 1878 1877 2013-07-19T15:00:42Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aformentioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> bd98fd8ae32c6c7ee4c99afa74b7fc9146f1ce78 1879 1878 2013-07-19T15:10:18Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aformentioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf rm ./problems.txt # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> dff3dd10ebd9e548f95dfcabfc2a6dedc52354e2 1880 1879 2013-07-19T15:15:02Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aformentioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf rm ./problems.txt # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> c8327926e2a11928b40c7f7a8b9219005ec8bf8e 1892 1880 2013-09-03T15:41:09Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Include the line setenv AMS_DIR /path/to/amslib somewhere. Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aformentioned folder and the text file inside it. To add other libraries to cadence edit the /cdsdir/IC_6.1xxx/share/cdssetup/cds.lib and add the line SOFTINCLUDE $AMS_DIR/artist/HK_C35/cds.lib or other libraries that are needed. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf rm ./problems.txt # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> f9539be762a02818c09f5ddad8007e15a833e18a 1893 1892 2013-09-03T15:42:11Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Include the line setenv AMS_DIR /path/to/amslib somewhere. Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aformentioned folder and the text file inside it. To add other libraries to cadence edit the /cdsdir/IC_6.1xxx/share/cdssetup/cds.lib and add the line SOFTINCLUDE $AMS_DIR/artist/HK_C35/cds.lib or other libraries that are needed. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf rm ./problems.txt # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> 1cd1765cb9b3ddffdaece9cbc1871738288caf88 1894 1893 2013-09-04T11:37:45Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar xvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 615 is for compability with IC5 (CDB), install folder is ASSURA_*_OA. 5141 is for use with IC6 (OA), install folder is ASSURA_*_CDB. === ALTOS === Altos doesn't use install manager and isn't caught by the untar program as it is a .tgz file. === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "production_cds_20xx_linux.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual foldernames are correct. *24 - Set correct license server at line *27 - Set top folder to /prog/candece *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *89+91 - Change tools to tools.lnx86 (check folder) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIV path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $incisiv_dir alias ams_cds_start 'ams_cds -64 -tech c35b4 -nologo' Save file as production_cds_20xx_linux_mod.csh csh chmod +x /prog/cadence/production_cds_20xx_linux_mod.csh source /prog/cadence/production_cds_20xx_linux_mod.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aformentioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2013 # if [ -z "$CDS_TOP" ] then echo "Please run environment script first" exit 1 fi # Add new modules if needed cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE $CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) # CTOS_ROOT doesn't seem to have a checksysconf rm ./problems.txt # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo $result if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done </script> == Linux packages that might be required == *openmotif *tk *ksh 93ab0fe54805b3cb111dc387d8bbe621b41df278 0 203 1881 1835 2013-07-31T13:10:53Z Ave082 33 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23, 28 or 57 to Blandonnet (stops under the bridge, go up and to the right in the middle of the stairs), and then change to the tram 18 "CERN" or Y "Val-Thoiry". Check [http://www.tpg.ch tpg.ch] for the timetable. Get off at the stop opposite the large wooden globe. To get to the busses from the airport you go left and into the area leading to the trains. Take the escalator to the second floor and the bus stop is right outside. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == To get into CERN if you don't have anybody to pick you up it is usually easiest to show your CERN contract to clerk at the visitors office, [http://building.web.cern.ch/map/building?bno=31 map]. * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, [http://building.web.cern.ch/map/building?bno=561 map]. *CERN drivings license, if you want to use the Bergen car. Bring your drivings license, as they need to scan it in. To get the license, you need security course, level 1+2, see below. When the secretariat have made the request, you will receive an email that you should sign the request. This you do at [http://edh.cern.ch edh.cern.ch], and for this you need a password, as described below. The car is usually located outside the Bergen Office (plate number GE 603658, car number 3948), but could also be located at the parking area by building 400. The key is in the office. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) b28ef4469741de7e144ce2a5ebdc789ccc1dc85d 1882 1881 2013-07-31T13:19:42Z Ave082 33 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23, 28 or 57 to Blandonnet (stops under the bridge, go up and to the right in the middle of the stairs), and then change to the tram 18 "CERN" or Y "Val-Thoiry". Check [http://www.tpg.ch tpg.ch] for the timetable. Get off at the stop opposite the large wooden globe. To get to the busses from the airport you go left and into the area leading to the trains. Take the escalator to the second floor and the bus stop is right outside. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == To get into CERN if you don't have anybody to pick you up it is usually easiest to show your CERN contract to clerk at the visitors office, [http://building.web.cern.ch/map/building?bno=31 map]. * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, [http://building.web.cern.ch/map/building?bno=561 map]. ===CERN car=== You need to get a CERN car driving authorization from [https://edh.cern.ch/Document/General/DA here]. A scanned copy of your license needs to be attached. To get the license, you need security course, level 1+2, see below. The car is usually located outside the Bergen Office (plate number GE 603658, car number 3948), but could also be located at the parking area by building 400. The key is in the office. For other information [http://gs-dep.web.cern.ch/en/content/Mobility/CERN_car see]. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 364efef96f47161bd88147589b181d010f7d45a0 1883 1882 2013-07-31T13:20:42Z Ave082 33 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23, 28 or 57 to Blandonnet (stops under the bridge, go up and to the right in the middle of the stairs), and then change to the tram 18 "CERN" or Y "Val-Thoiry". Check [http://www.tpg.ch tpg.ch] for the timetable. Get off at the stop opposite the large wooden globe. To get to the busses from the airport you go left and into the area leading to the trains. Take the escalator to the second floor and the bus stop is right outside. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == To get into CERN if you don't have anybody to pick you up it is usually easiest to show your CERN contract to clerk at the visitors office, [http://building.web.cern.ch/map/building?bno=31 map]. * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, [http://building.web.cern.ch/map/building?bno=561 map]. *Alice registration. ===CERN car=== You need to get a CERN car driving authorization from [https://edh.cern.ch/Document/General/DA here]. A scanned copy of your license needs to be attached. To get the license, you need security course, level 1+2, see below. The car is usually located outside the Bergen Office (plate number GE 603658, car number 3948), but could also be located at the parking area by building 400. The key is in the office. For other information [http://gs-dep.web.cern.ch/en/content/Mobility/CERN_car see]. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) cefd557d39b2067fbfce11a900bac2b9624654e2 0 286 1884 1176 2013-08-20T13:34:31Z Tni071 73 Should be "Pad Round 65, Hole Rnd 41", not "Pad Round 65, Hole Rnd 41". wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 65, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Symbols" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. [[Image:amp215_symbol.png|centre|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Parts" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Parts" folder in the Library Navigator Tree. # Create a new “Part” called “amp01”. (The Part Editor dialogue should pop-up.) # Change the Number to "Opamp1". Change the Label to "amp01A". # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, "A single amplifier packaged". # Specify a Reference des prefix of "U". # On the Part Editor dialog, click the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), click the Import button. # On the Import dialog, select the symbol name amp215 from the list (select "amplifiers" from the Central Library, and then the Symbol name). # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # Click the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # Click the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # Click the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # Click the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the Part Editor. [[Image:amp1_pin_mapping.png|centre|Pin mapping dialogue the OpAmp]] ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # Click button “layout templates”. # Click once on the “4 layer Template” and press the “copy template” button above. # Click once on the copied template and give it the name “lab1 template”. # Click once on the “edit template” button. A default template is opened in “Expedition PCB”. # Click on the menu “Setup>Setup Parameters”. # In the “General” tap set the “number of physical layers” to 6. “Display units” should be set to “microns” and “meters/s”. Click on “Apply”. # In the “Layer Stackup” tab change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “OK”. # “Save” the template and “exit”. [[Category:Mikroelektronikk]] db4bf91fbd37a399f281894347284ad2f7c358f3 1885 1884 2013-08-20T13:35:16Z Tni071 73 Reverted edits by [[Special:Contributions/Tni071|Tni071]] ([[User talk:Tni071|talk]]) to last revision by [[User:Nfyku|Nfyku]] wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 64, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Symbols" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. [[Image:amp215_symbol.png|centre|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Parts" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Parts" folder in the Library Navigator Tree. # Create a new “Part” called “amp01”. (The Part Editor dialogue should pop-up.) # Change the Number to "Opamp1". Change the Label to "amp01A". # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, "A single amplifier packaged". # Specify a Reference des prefix of "U". # On the Part Editor dialog, click the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), click the Import button. # On the Import dialog, select the symbol name amp215 from the list (select "amplifiers" from the Central Library, and then the Symbol name). # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # Click the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # Click the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # Click the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # Click the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the Part Editor. [[Image:amp1_pin_mapping.png|centre|Pin mapping dialogue the OpAmp]] ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # Click button “layout templates”. # Click once on the “4 layer Template” and press the “copy template” button above. # Click once on the copied template and give it the name “lab1 template”. # Click once on the “edit template” button. A default template is opened in “Expedition PCB”. # Click on the menu “Setup>Setup Parameters”. # In the “General” tap set the “number of physical layers” to 6. “Display units” should be set to “microns” and “meters/s”. Click on “Apply”. # In the “Layer Stackup” tab change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “OK”. # “Save” the template and “exit”. [[Category:Mikroelektronikk]] ba76be99fefc9757b79d99ec1d6d2ce82ebab987 1886 1885 2013-08-20T13:36:07Z Tni071 73 Should be "Pad Round 65, Hole Rnd 41", not "Pad Round 64, Hole Rnd 41" wikitext text/x-wiki This lab is designed to teach you the basic workflow for creating a simple printed circuit board using the Mentor Graphics Expedition PCB tools. You will be looking at editor environments and fundamental library concepts. You will learn how to create padstacks and cells. You will eventually assemble databases for creating parts. ===Schedule=== Lab 1 (4 hours) * Introduction to Expedition PCB * LIBRARY & DATA OVERVIEW (15 min) * CREATING PADSTACKS : exercise (45 min) * CREATING CELLS : exercise (45 min) * CREATING SYMBOLS : exercise (15 min) * CREATING PARTS : exercise (30 min) * CREATING A CUSTOM LAYOUT TEMPLATE : exercise (15 min) ==Introduction to Expedition PCB== Open the dashboard application /prog/mentor/ee2007.7/2007.7EE/SDD_HOME/common/linux/bin/dash & . The left panel (Shortcuts) is for placing shortcuts to applications. Drag the ExpeditionPCB, ePlanner, DxDesigner, and Library Manager icons to the Shortcuts area from the Toolboxes directories. Expedition PCB is the High-Speed (HS) layout tool. ePlanner is the tool for setting up the HS constraints. DxDesigner is the schematic capture tool, while the Library Manager allows you to create pad stacks, cells, symbols, and parts. Your projects will listed as they are created. ==PART 1 PADSTACK DEFINITION== # Open the “Library Manager” and create a new library for example under directory $HOME/kurs/lab1. What you do is to create a new directory $HOME/kurs/lab1/ and the library manager will create a number of files and directories in there. # Click on the “Setup” menu and select “Partition Editor”, or use the buttons under the menus. See that there are initially only 25 symbols declared and no cells, no PDBs and no IBIS models. Click on “cancel”. #: You can always chose between menus and buttons. # Under “Setup” select “Setup Parameters”. See that under “General” nothing is declared, but under “Via Definitions” there is only one standard padstack declared called “L: 026VIA”. Select “close”. # Select the button “Library Services”. Select “Padstacks” menu and select with the browser for the “input from” to “/heim/kjetil/mgc/phys321.lmc”. Click on “open”. # Select from “Padstacks in import partition” the “IPC, SOIC” and "Pad Round 65, Hole Rnd 41" padstacks. Be sure you select mode = “copy”. Press the “right arrow” and then “apply”. See that in the left table, the imported padstacks (for example the “IPC, SOIC”) will have a blue color. Select “close”. # Select in the "Library Navigator Tree" the “Padstacks" item (folder). You should now have two padstack declarations under item "All". Examine the properties of both padstack declarations by double clicking on one of them. # Examine the menus “Pads” and “Holes” from the “Padstack Editor”. Click in the menus once on the declared names listed and examine their declarations. ===Exercise=== Create a padstack definition for the through hole via with min. 250 &mu;m and pad min. 450 &mu;m (Hint: define first the “hole” and then the “pads” you need. Finally create the “padstack” with the newly declared “hole” and “pads” definitions.) ===Summary=== You now have learned how to create your own library; copy padstack definitions from other libraries and create your own padstacks with help of documents you get from the PCB manufacturer. ==PART 2 CREATING NEW CELLS== You should have the “lab1” Library open in the Library Manager. # Right-click on the "Cells" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" section and select "New Cell". # Enter the Cell name "8SO". # Specify a Total number of pins of 8. Specify a Layers while editing cell of 4. Choose the IC – SOIC Package group. # Click the "Cell Properties" button. Enter a description of SOIC 8. Set the Units to mm. Specify a Height of 1.75. # On the Package Cell Properties dialogue, <click> the Close button. # On the Create Package Cell dialogue, <click> the Next button and the Cell Editor tool should open. # On the Place Pins dialogue, click the Pin # column until the pins are sorted from 1 to 8. # Select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the Shift key, click the down arrow in the Padstack Name field for pin 8, and choose the SOIC padstack from the pulldown list. It should now be assigned to all of the pins. # Click the Pattern Place tab. # Set the Pattern type to SOIC and enter the following values into the pattern form: #: Body length = 5 #: Body width = 3 #: Pin to pin spacing = 1.27 #: Row to row spacing = 5.2 #: Make sure the Include Assembly outline and Include Silkscreen outline option are checked. # With the pins still selected, <click> the Place button. # Click the Close button on the Place Pins dialogue. # Examine the graphics. Select File>Save from the menus and then select File>Exit Graphics from the menus. # Click the S80 symbol to examine the Preview of the new cell. # Click the New Cell button. # Enter the Cell name 8DIP. # Set the Total number of pins to 8. Set the Layers while editing cell to 4. Choose the IC - DIP Package group. # Click the Cell Properties button. Enter a description of DIP 8. Verify that the Units is set to th.(=mil) Specify a Height of 100. Click the Close button. # On the Create Package Cell dialog, click the Next button. # Move the Place Pins dialog out of the way. # In the graphics environment, select Setup > Editor Control from the menus. # Select the Grids tab. Specify a Route grid of 25 and a Drawing grid of 25. # On the Place Pins dialogue, select the Padstack Name field for pin 1. Press and hold the <Shift> key then select the Padstack Name field for pin 8. # Continuing to hold the <Shift> key, <click> the down arrow in the Padstack Name field for pin 8 and choose the through via Pad Round 65, Hole Rond 41 (the one from previous exercise) from the pulldown list. It should then be assigned to all of the pins. # Click the Parameter Place tab and enter the following values: #: Columns: 4 Spacing: 100 #: Rows: 2 Spacing: 300 #: Pin Sequence = first option. # Click the Place button. # Position the cursor over the drawing area. The pins are attached to the cursor for placement. Click directly on the “origin” marker to place them down. # Select View>Fit All from the menus. # Select Edit>Place>Assembly Outline from the menus. Using the Rectangle draw tool, draw a rectangle inside of all the pins. Draw any other assembly graphics you desire by selecting another draw tool. # Select Edit>Place>Silkscreen Outline from the menus. Draw a rectangle outside of all the pins. Draw any other silkscreen graphics you desire. # Select Edit>Place>Placement Outline. Draw a rectangle a little larger than the silkscreen outline. # Move Reference Designator and Part Number text as desired by first selecting the text, positioning the mouse cursor over the text border until a “move” cursor appears, then click-drag the text. # Select Edit>Place>Silkscreen Ref Des from the menus and place the text outside of the silkscreen outline. # Select File>Save from the menus. # Select File>Exit Graphics from the menus. # Select each cell in the list to see a Preview of it. ==PART 3 CREATING SYMBOLS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Symbols" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Symbols" folder in the Library Navigator Tree. # Create a new “Symbol” called “amp215”. (A graphical editor should pop-up.) # Examine the window and create the opamp as pictured below: (don’t forget to give the pins properties e.g. “input” property or “output” property.) # Save your work and exit the “Symbol Editor”. During “saving”, the design is checked against DRC rules. [[Image:amp215_symbol.png|centre|Symbol to draw for the OpAmp]] ==PART 4 CREATING PARTS== You should have the “lab1” Central Library open in the Library Manager. # Right-click on the "Parts" folder in the Library Navigator Tree. # Create a new “Partition” called “amplifiers”. # Right-click on the "amplifiers" folder under the "Parts" folder in the Library Navigator Tree. # Create a new “Part” called “amp01”. (The Part Editor dialogue should pop-up.) # Change the Number to "Opamp1". Change the Label to "amp01A". # At the lower-left corner of the PartsDB Editor dialog, verify that the Component property value for Type is IC. # Enter the Description of IC, "A single amplifier packaged". # Specify a Reference des prefix of "U". # On the Part Editor dialog, click the Pin Mapping button. # In the Assign symbols section of the dialog (upper-left corner), click the Import button. # On the Import dialog, select the symbol name amp215 from the list (select "amplifiers" from the Central Library, and then the Symbol name). # Select Create New gate information option. # Enter the Number of slots as 1. # Select the Include pin properties option. # Click the OK button. A new gate will be created in the Logical table with 4 slots. # In the Assign package cell section of the dialog (upper-right corner), click on the Import button. # On the Import dialog, select 8DIP from the list of cells and <click> the OK button. # Examine the Logical table and Physical table at the bottom of the Pin Mapping dialog. The symbol imported with 1 slot defined. # Click the Physical tab. Enter the following physical pin outs: #: In1 2 #: In2 3 #: VCC 6 #: GND 7 #: Out 8 # Click the Supply and NC tab. # Enter a Pin # of 1,4,5 for NC. # Click the OK button on the Pin Mapping dialog to save your work. # Select File>Save from the menus. # Exit the Part Editor. [[Image:amp1_pin_mapping.png|centre|Pin mapping dialogue the OpAmp]] ==PART 5 CREATING A LAYOUT TEMPLATE== You should have the “lab1” Central Library open in the Library Manager. # Click button “layout templates”. # Click once on the “4 layer Template” and press the “copy template” button above. # Click once on the copied template and give it the name “lab1 template”. # Click once on the “edit template” button. A default template is opened in “Expedition PCB”. # Click on the menu “Setup>Setup Parameters”. # In the “General” tap set the “number of physical layers” to 6. “Display units” should be set to “microns” and “meters/s”. Click on “Apply”. # In the “Layer Stackup” tab change for all dielectric layers thickness the value to “500 um”. Make sure you select the option “keep layer stackup in sync with layer def. In Planes tab.” # Select “OK”. # “Save” the template and “exit”. [[Category:Mikroelektronikk]] db4bf91fbd37a399f281894347284ad2f7c358f3 0 416 1887 1862 2013-08-22T10:12:19Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= * Rightclick in the library pan of Questasim and choose new->Library. * Choose "A map to an existing library". * Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. * Include the library in the files where you need SF2 cores The same applies for other actel devices. =Libero errors, warnings and problems= * If you get "Warning: CMP008: module_name is not an Actel cell defined in the cell library." it means the mentioned module was not included in the synthesis and thus assumed to be an Actel standard module. Rightclick synthesis and select "Organize input files->Organize source files" select the mentioned module and press add. 10ed4bdfaa2fce5e283f198d8330fa2af14a038d 1888 1887 2013-08-22T10:22:53Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= * Rightclick in the library pan of Questasim and choose new->Library. * Choose "A map to an existing library". * Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. * Include the library in the files where you need SF2 cores The same applies for other actel devices. =Libero errors, warnings and problems= * If you get "Warning: CMP008: module_name is not an Actel cell defined in the cell library." it means the mentioned module was not included in the synthesis and thus assumed to be an Actel standard module. Rightclick synthesis and select "Organize input files->Organize source files" select the mentioned module and press add. * Generate programming data fails without explanation: Constraint format has changed between Libero versions. Generate a new constraint file using the I/O editor based on the data in the old constraint file. 03c24bcdc794429e726d79d993b2a04925f11f4d 1889 1888 2013-08-26T13:54:27Z Ave082 33 wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Other designfiles and documents can be found here: http://emcraft.com/products/153 Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= * Rightclick in the library pan of Questasim and choose new->Library. * Choose "A map to an existing library". * Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. * Include the library in the files where you need SF2 cores The same applies for other actel devices. =Libero errors, warnings and problems= * If you get "Warning: CMP008: module_name is not an Actel cell defined in the cell library." it means the mentioned module was not included in the synthesis and thus assumed to be an Actel standard module. Rightclick synthesis and select "Organize input files->Organize source files" select the mentioned module and press add. * Generate programming data fails without explanation: Constraint format has changed between Libero versions. Generate a new constraint file using the I/O editor based on the data in the old constraint file. 6ad753c2a13bfe9f791985b01ef83bd6e9e64953 0 38 1890 1222 2013-09-02T16:11:26Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence_init.csh virtuoso Virtuoso Mixed Signal Design Environment should now start up: <img src="uploads/icms_uppstart.JPG" /> In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. <img src="uploads/new_library.JPG" /> After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name (for example "torcell", as I did). You must also specify which library the design belongs to, and here you specify the library that you have just created (in my case, TORLIB). Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. <img src="uploads/create_new_file.JPG" /> Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: <img src="uploads/virtuoso_schematic_editor.JPG" /> ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB"?!?(analogLib) as library, "nmos" (for n-type transistor) or "pmos" (for p-type transistor) as cell and "spectreS"?!?(symbol) as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. <img src="uploads/library_browser.JPG" /> 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. For the transistors, set the "Width" and "Lenght" properties to "4u" and "1u". For the pmos transistor, set the "Model name" property to "modp". For the nmos transistor, set the "Model name" property to "modn". As we will see later, the "modn" and "modp" models correspond to SPICE simulation models used by the simulator in the Analog Environment. <img src="uploads/edit_object_properties.JPG" /> <img src="uploads/edit_object_prop_pmos.JPG" /> 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Tools > Analog Environment". The "Virtuoso Analog Environment" should now come up: <img src="uploads/analog_env_1.JPG" /> ==Simulating the design== 8. Choose "Launch > ADE GXL" and press create new view. 9. Choose "Create > Test..." select the cell to simulate. 10. Choose "Simulation > Netlist > Create Raw". 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. <img src="uploads/choosing_analyses.JPG" /> <img src="uploads/select_comp_parameter.JPG" /> The analog environment should now look like this: <img src="uploads/analog_env_2.JPG" /> 13. Choose "Simulation > Run". 14. After the simulation has completed, choose "Results > Plot Outputs > DC". The outputs should look like this: <img src="uploads/plot_output_dc.JPG" /> To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. <img src="uploads/add_pin.JPG" /> After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". <img src="uploads/create_cellview_from_cellview.JPG" /> Now press OK: <img src="uploads/symbol_generation_options.JPG" /> Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: <img src="uploads/symbol_editor.JPG" /> Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 17184c41f91c70ce3e574288df52dd0ca5d39cd6 1891 1890 2013-09-03T14:36:23Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence_init.csh virtuoso Virtuoso Mixed Signal Design Environment should now start up: <img src="uploads/icms_uppstart.JPG" /> In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. <img src="uploads/new_library.JPG" /> After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name (for example "torcell", as I did). You must also specify which library the design belongs to, and here you specify the library that you have just created (in my case, TORLIB). Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. <img src="uploads/create_new_file.JPG" /> Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: <img src="uploads/virtuoso_schematic_editor.JPG" /> ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB"?!?(analogLib) as library, "nmos" (for n-type transistor) or "pmos" (for p-type transistor) as cell and "spectreS"?!?(symbol) as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. <img src="uploads/library_browser.JPG" /> 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. For the transistors, set the "Width" and "Lenght" properties to "4u" and "1u". For the pmos transistor, set the "Model name" property to "modp". For the nmos transistor, set the "Model name" property to "modn". As we will see later, the "modn" and "modp" models correspond to SPICE simulation models used by the simulator in the Analog Environment. <img src="uploads/edit_object_properties.JPG" /> <img src="uploads/edit_object_prop_pmos.JPG" /> 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Tools > Analog Environment". The "Virtuoso Analog Environment" should now come up: <img src="uploads/analog_env_1.JPG" /> ==Simulating the design== 8. Choose "Launch > ADE GXL" and press create new view. 9. Choose "Create > Test..." select the cell to simulate. 10. Choose "Simulation > Netlist > Create". 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. <img src="uploads/choosing_analyses.JPG" /> <img src="uploads/select_comp_parameter.JPG" /> The analog environment should now look like this: <img src="uploads/analog_env_2.JPG" /> 13. Choose "Simulation > Run". 14. After the simulation has completed, choose "Results > Plot Outputs > DC". The outputs should look like this: <img src="uploads/plot_output_dc.JPG" /> To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. <img src="uploads/add_pin.JPG" /> After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". <img src="uploads/create_cellview_from_cellview.JPG" /> Now press OK: <img src="uploads/symbol_generation_options.JPG" /> Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: <img src="uploads/symbol_editor.JPG" /> Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 56ac67e82d0eb21d78eeb95701f76b15e698a525 1895 1891 2013-09-04T13:11:32Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up: [[File:icms_uppstart.jpg]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. [[File:new_library.jpg]] After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. [[File:create_new_file.jpg]] Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.jpg]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. [[File:library_browser.jpg]] 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. [[File:edit_object_properties.jpg]] [[File:edit_object_prop_pmos.jpg]] 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up: [[File:analog_env_1.jpg]] ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:choosing_analyses.jpg]] [[File:select_comp_parameter.jpg]] The analog environment should now look like this: [[File:analog_env_2.jpg]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.jpg]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. [[File:add_pin.jpg]] After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". [[File:create_cellview_from_cellview.jpg]] Now press OK: [[File:symbol_generation_options.jpg]] Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: [[File:symbol_editor.jpg]] Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] d03f6d61f3b572c3855863e8f57d9f08f2c38294 1896 1895 2013-09-04T13:37:23Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. [[File:create_new_file.jpg]] Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.jpg]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. [[File:library_browser.jpg]] 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. [[File:edit_object_properties.jpg]] [[File:edit_object_prop_pmos.jpg]] 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up: [[File:analog_env_1.jpg]] ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:choosing_analyses.jpg]] [[File:select_comp_parameter.jpg]] The analog environment should now look like this: [[File:analog_env_2.jpg]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.jpg]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. [[File:add_pin.jpg]] After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". [[File:create_cellview_from_cellview.jpg]] Now press OK: [[File:symbol_generation_options.jpg]] Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: [[File:symbol_editor.jpg]] Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 4d429e8c5e8bd5d9501a1ad3984d9cd166546623 1898 1896 2013-09-04T13:45:48Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png]] The analog environment should now look like this: [[File:analog_env_2.jpg]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. [[File:add_pin.jpg]] After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". [[File:create_cellview_from_cellview.jpg]] Now press OK: [[File:symbol_generation_options.jpg]] Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: [[File:symbol_editor.jpg]] Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 07d9a560dc4c8eb86af2542f0a4f75827f88243d 1900 1898 2013-09-04T13:47:49Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png]] The analog environment should now look like this: [[File:analog_env_2.png]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. [[File:add_pin.jpg]] After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". [[File:create_cellview_from_cellview.jpg]] Now press OK: [[File:symbol_generation_options.jpg]] Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: [[File:symbol_editor.jpg]] Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] fb9fb64ade04ce317b35a7a0e62fa3695391c838 1903 1900 2013-09-04T13:51:09Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|400px]] The analog environment should now look like this: [[File:analog_env_2.png|400px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|400px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. [[File:add_pin.jpg]] After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". [[File:create_cellview_from_cellview.jpg]] Now press OK: [[File:symbol_generation_options.jpg]] Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: [[File:symbol_editor.jpg]] Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 16f2b24dfda64ab1f8093e85dc014db9ed2cc99a 1904 1903 2013-09-04T13:51:49Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|200px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. [[File:add_pin.jpg]] After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". [[File:create_cellview_from_cellview.jpg]] Now press OK: [[File:symbol_generation_options.jpg]] Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: [[File:symbol_editor.jpg]] Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] 614598c2b5a58beff34b586cbf33de2cad791ff5 1905 1904 2013-09-04T13:52:16Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). First we return to the schematic editor to add the IN and OUT pins that connect our inverter to the outside world. Click at the "Pin" symbol or press 'p' to place pins. Connect an input pin to the inverter input and an output pin to the inverter output. [[File:add_pin.jpg]] After checking and saving the design, choose "Design -> Create Cellview -> From Cellview". [[File:create_cellview_from_cellview.jpg]] Now press OK: [[File:symbol_generation_options.jpg]] Connect the left pin to the input pin and the right pin to the output pin. Then press OK. The symbol editor will pop up: [[File:symbol_editor.jpg]] Draw the symbol in whatever way you want, and then save it by clicking the "Save" symbol or pressing 'S'. [[Category:Mikroelektronikk]] e7d9622f92a4271e18ff7edea47f023af63b7175 1906 1905 2013-09-04T14:05:20Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol- [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] 4d86597184c3ed5d83fb97d9f5a57fe30aac9e3d 6 418 1897 2013-09-04T13:44:11Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 419 1899 2013-09-04T13:46:53Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 420 1901 2013-09-04T13:48:00Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 421 1902 2013-09-04T13:49:52Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 422 1907 2013-09-04T14:06:30Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 224 1908 760 2013-09-08T22:17:26Z Ave082 33 wikitext text/x-wiki LTspice file:[spice.asc] <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD VSS 3 * Transistor * Drain Gate Source Bulk MN1 Out In VSS VSS nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out VSS 0.1p * Voltage source * from to volts VI In VSS DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0.2 + TOX=10e-9 PHI=0.93 GAMMA=0.6 + CJ=9.8E-5 PB=0.72 MJ=0.36 + CJSW=2.2E-10 MJSW=0.1) * * Setup * .options nomod nopage .width OUT=80 .connect vss 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] 0bee3efb1e739efc6090a58aaeae919d1d45263b 1909 1908 2013-09-08T22:21:34Z Ave082 33 wikitext text/x-wiki LTspice file:[Media:spice.asc] <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD VSS 3 * Transistor * Drain Gate Source Bulk MN1 Out In VSS VSS nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out VSS 0.1p * Voltage source * from to volts VI In VSS DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0.2 + TOX=10e-9 PHI=0.93 GAMMA=0.6 + CJ=9.8E-5 PB=0.72 MJ=0.36 + CJSW=2.2E-10 MJSW=0.1) * * Setup * .options nomod nopage .width OUT=80 .connect vss 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] 812cbf2fc62c05372e467cea8c09ff2108fb1f86 1910 1909 2013-09-08T22:21:57Z Ave082 33 wikitext text/x-wiki LTspice file:[[Media:spice.asc]] <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD VSS 3 * Transistor * Drain Gate Source Bulk MN1 Out In VSS VSS nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out VSS 0.1p * Voltage source * from to volts VI In VSS DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0.2 + TOX=10e-9 PHI=0.93 GAMMA=0.6 + CJ=9.8E-5 PB=0.72 MJ=0.36 + CJSW=2.2E-10 MJSW=0.1) * * Setup * .options nomod nopage .width OUT=80 .connect vss 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] 47dc94de33ac260264146c226ca97b1b725abb86 1912 1910 2013-09-08T22:24:49Z Ave082 33 wikitext text/x-wiki LTspice file:[[Media:spice.asc.txt]] <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD GND 3 * Transistor * Drain Gate Source Bulk MN1 Out In GND GND nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out GND 0.1p * Voltage source * from to volts VI In GND DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0.2 + TOX=10e-9 PHI=0.93 GAMMA=0.6 + CJ=9.8E-5 PB=0.72 MJ=0.36 + CJSW=2.2E-10 MJSW=0.1) * * Setup * .options nomod nopage .width OUT=80 *.connect GND 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] 41a67ea18c92b42c6be3f68fd93770fd50a2a563 1913 1912 2013-09-08T22:25:19Z Ave082 33 wikitext text/x-wiki LTspice file:[[Media:spice.asc.txt]] (Rename to spice.asc after downloading) <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD GND 3 * Transistor * Drain Gate Source Bulk MN1 Out In GND GND nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out GND 0.1p * Voltage source * from to volts VI In GND DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0.2 + TOX=10e-9 PHI=0.93 GAMMA=0.6 + CJ=9.8E-5 PB=0.72 MJ=0.36 + CJSW=2.2E-10 MJSW=0.1) * * Setup * .options nomod nopage .width OUT=80 *.connect GND 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] ff3f08d33e9bff0c187079cf79b92b50ffeb33a6 1914 1913 2013-09-08T22:25:53Z Ave082 33 wikitext text/x-wiki LTspice file:[[Media:spice.asc.txt|Spice file]] (Rename to spice.asc after downloading) <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD GND 3 * Transistor * Drain Gate Source Bulk MN1 Out In GND GND nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out GND 0.1p * Voltage source * from to volts VI In GND DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0.2 + TOX=10e-9 PHI=0.93 GAMMA=0.6 + CJ=9.8E-5 PB=0.72 MJ=0.36 + CJSW=2.2E-10 MJSW=0.1) * * Setup * .options nomod nopage .width OUT=80 *.connect GND 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] 4db73601f3d8b66c8302209f1a910f85b45328fb 1915 1914 2013-09-09T10:21:41Z Ave082 33 wikitext text/x-wiki LTspice file:[[Media:spice.asc.txt|Spice file]] (Rename to spice.asc after downloading) <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD GND 3 * Transistor * Drain Gate Source Bulk MN1 Out In GND GND nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out GND 0.1p * Voltage source * from to volts VI In GND DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0) * * Setup * *.options nomod nopage *.width OUT=80 *.connect GND 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] afde1450650bc8f7a7b260799adb521224ec21c9 1916 1915 2013-09-09T10:24:39Z Ave082 33 wikitext text/x-wiki LTspice file:[[Media:spice.asc.txt|Spice file]] (Rename to spice.asc after downloading) Select output node after running simulation and change the vertical scale to volts to see output level. Choose View->Spice Error Log to view operating point. <pre> Common Source gain stage, max gain * Analysis and design of analog integrated circuits * Problem 3.4 * NB ! Model level 1 only - Similar to hand calcualtions * * Voltage * from to volts VDD VDD GND 3 * Transistor * Drain Gate Source Bulk MN1 Out In GND GND nmos W=10u L=1u * Load Resistor and Capacitor * from to ohms RD VDD Out 5k Cl Out GND 0.1p * Voltage source * from to volts VI In GND DC 1.281 AC 1 * * Models * .model nmos nmos (level=1 VT0=0.6 KP=200u LAMBDA=0) * * Setup * *.options nomod nopage *.width OUT=80 *.connect GND 0 * * Simulation and Plots * *.TF V(Out) VI *.OP .ac dec 10 1k 100.0e9 * Amplitude Bode Plot .plot ac vdb(Out) * Phase Bode Plot .plot ac vp(Out) .END </pre> [[Category:Mikroelektronikk]] aea54b48c2bab6090b3510cb654e7d247a032b65 6 423 1911 2013-09-08T22:23:52Z Ave082 33 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1917 1911 2013-09-09T10:28:29Z Ave082 33 Ave082 uploaded a new version of &quot;[[File:Spice.asc.txt]]&quot; wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 25 1918 1841 2013-09-24T09:14:45Z Cto070 76 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[SmartFusion2]] Oppsett og design med SF2 * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus [[Category:Mikroelektronikk]] 2b6b0276974cfafa939287d9c8a37329662c954d 0 424 1919 2013-09-24T12:14:54Z Cto070 76 Created page with "=Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with ..." wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project 868217dc2f6e269637093cdeadbdfe2cdd2aa9d7 1920 1919 2013-09-24T12:29:30Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''.[[File:New_project.jpg]] 4e0a86990f978bb29d38ce07a6e858066b411d4d 1922 1920 2013-09-26T12:53:42Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg]]<br> MSS CCC<br>[[File:MSS_reset.jpg]]<br> Reset Controller<br>[[File:FIC0.jpg]]<br> FIC 0<br>[[File:MMUART.jpg]]<br> MMUART 0 Your MSS should now look like this: [[File:MSS_finished.jpg]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg]][[File:CCC_core.jpg]] Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''. [[File:Module_bus_interface.jpg]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg]] e2b282b6965aab811ccd4f685bff6a2fe1433058 1923 1922 2013-09-26T13:29:00Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg]]<br> MSS CCC<br>[[File:MSS_reset.jpg]]<br> Reset Controller<br>[[File:FIC0.jpg]]<br> FIC 0<br>[[File:MMUART.jpg]]<br> MMUART 0 Your MSS should now look like this: [[File:MSS_finished.jpg]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg]][[File:CCC_core.jpg]] Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''. [[File:Module_bus_interface.jpg]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= Use run.do supplied and user.bfm 12c327ea23b0d009753d17a96d11ae1efe923b8a 0 424 1924 1923 2013-09-27T12:16:13Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg]]<br> MSS CCC<br>[[File:MSS_reset.jpg]]<br> Reset Controller<br>[[File:FIC0.jpg]]<br> FIC 0<br>[[File:MMUART.jpg]]<br> MMUART 0 Your MSS should now look like this: [[File:MSS_finished.jpg]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg]][[File:CCC_core.jpg]] Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''. [[File:Module_bus_interface.jpg]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design''. [[File:Presynth_transcript.jpg]]<br>[[File:Presynth_wave.jpg]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause this LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. 26239a2de5095fbd95b7e4b496dffec7a5bedf0b 1925 1924 2013-09-27T12:42:18Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg]]<br> MSS CCC<br>[[File:MSS_reset.jpg]]<br> Reset Controller<br>[[File:FIC0.jpg]]<br> FIC 0<br>[[File:MMUART.jpg]]<br> MMUART 0 Your MSS should now look like this: [[File:MSS_finished.jpg]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg]][[File:CCC_core.jpg]] Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''. [[File:Module_bus_interface.jpg]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design''. [[File:Presynth_transcript.jpg]]<br>[[File:Presynth_wave.jpg]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause this LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. [[File:Debug_configuration.jpg]][[File:Debugging.jpg]][[File:Debug_binary_count.jpg]] 1668bf3910f40c408ce5779d97f514a3efeee346 1945 1925 2013-09-28T08:10:57Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|500 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|400 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''. [[File:Module_bus_interface.jpg]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design''. [[File:Presynth_transcript.jpg]]<br>[[File:Presynth_wave.jpg]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause this LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. [[File:Debug_configuration.jpg]][[File:Debugging.jpg]][[File:Debug_binary_count.jpg]] d109e0a0a9ff1ba8027445e375ed804544a344cc 1946 1945 2013-09-28T08:19:14Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|400 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|500 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause this LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> bb24e856b89b2482f46a7b1b657ebc7f24711d56 1947 1946 2013-09-28T08:21:52Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause this LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> ae119b27996e7a268b5ba09dfe4dfb830c15ce40 1948 1947 2013-09-28T08:59:39Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to create a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> 39019af84aa6a593ad0b03a0aea0c616868cc6a9 1949 1948 2013-09-28T09:00:20Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial a UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> 9d5336980c1c124c4c56dcf289437418db8399d4 1950 1949 2013-09-28T09:01:12Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Actel. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> c709630acee0bf690d2d64dca844daf24e278d81 1951 1950 2013-09-28T09:01:46Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. You can name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> 4eb67670c7a0b026fe89aca0570b7365c389348d 1952 1951 2013-09-28T09:02:22Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now, Import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this, you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> ad77c67f06b58dc55a17aa097b4ee62ca7c28439 1953 1952 2013-09-28T09:42:01Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> 7ba9fc420899406b12239131247b8417fb2f935c 1954 1953 2013-09-30T06:40:04Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. [[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals. [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> c04cd5b25264ad0882b7021646590466c0f29730 1958 1954 2013-09-30T07:56:07Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> 125b494b31f8244c97945791b404f2a4d8bf4247 1959 1958 2013-09-30T08:24:50Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> [[Category:Mikroelektronikk]] 4401cea8601c1a0e19c431c4a08cf03f36d17d3a 1960 1959 2013-09-30T09:02:10Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files [[Media:APB_DCS_files.zip]] by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). In the supplied files there is a file called User.bfm. Copy the content of this file to the User.bfm in your project, located under ''Files'' and ''simulation''. Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> ------------------------------------------------------------------------------- -- Title : APB_to_DCS -- Project : RCU2 ------------------------------------------------------------------------------- -- File : apb_to_dcs.vhd -- Last edited by : Christian Torgersen -- Last update : 30.09.2013 - 09:26 -- Current Revision : 1.0 ------------------------------------------------------------------------------- -- Description : Mapping between AMBA APB and DCS bus. ------------------------------------------------------------------------------- -- Revision History : ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway -- This file has been written by Christian Torgersen -- Christian.torgersen@student.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; library work; use work.dcs_interface_pkg.all; entity apb_to_dcs is port( --APB input control signals penable : in std_logic; -- APB enable signal. Asserted high on second pulse psel : in std_logic; -- APB slave select from master pwrite : in std_logic; -- APB direction setting --APB input and addr paddr : in std_logic_vector(31 downto 0); -- APB address pwdata : in std_logic_vector(31 downto 0); -- APB write data --APB output signals prdata : out std_logic_vector(31 downto 0); -- APB read data pready : out std_logic; -- APB hold signal, for read/write more than 2 cycles pslverr : out std_logic; -- APB slave error signal clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity reset_from_siu : in std_logic; -- asynch reset from SIU, positive polarity --internal resets global_reset : out std_logic; -- global reset, positive polarity rcu_reset : out std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : out std_logic; -- reset for FEC, positive polarity --DCS bus signals we_dcs : out std_logic; -- write enable to the internal modules dcs_busBadd : out std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : out std_logic; -- interrupt in case DCS needs bus dcs_bg : in std_logic; -- dcs bus grant from arbiter dcs_br : out std_logic; -- dcs bus request to arbiter siu_bg : in std_logic -- siu bus grant from arbiter ); end apb_to_dcs; architecture arc of apb_to_dcs is --signal declarations type state is (s_idle, s_wait_for_grant, s_grant, s_error); signal current_state, next_state : state; -- signal resetting : std_logic; -- high when the resetting addresses are received, only used by dcs_addr signal timeout :std_logic; signal timeout_cnt :std_logic_vector(6 downto 0); signal timeout_cnt_en :std_logic; signal we_dcs_i :std_logic; begin --combinatorics timeout <= timeout_cnt(6); we_dcs <= we_dcs_i; dcs_br <= '1' when (psel = '1'and (next_state = s_wait_for_grant or next_state = s_grant)) else '0'; dcs_busBadd <= paddr(15 downto 0); --linking between APB and dcs addresses dcs_busBdata_out <= pwdata when (pwrite='1' and dcs_bg= '1') else (others => '0'); -- APB to DCS data prdata <= dcs_busBdata_in when (pwrite ='0' and dcs_bg= '1') else (others => '0'); -- DCS to APB data -- purpose: timeout counter for transaction p_timeout_cnt: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt <= (others => '0'); elsif rising_edge(clk) then if (timeout_cnt_en = '1') then timeout_cnt <= timeout_cnt + 1; else timeout_cnt <= (others => '0'); end if; end if; end process p_timeout_cnt; -- purpose: state machine driver p_state_driver: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then current_state <= s_idle; elsif rising_edge(clk) then current_state <= next_state; end if; end process p_state_driver; --purpose: set next state p_next_state: process(current_state, dcs_bg, timeout, psel, penable) begin case current_state is when s_idle => if (dcs_bg = '1' and psel = '1' and penable = '0') then -- giving two cycle read/write possibility next_state <= s_grant; elsif (dcs_bg = '0' and psel = '1' and penable = '0') then --Three or more cycle read/write next_state <= s_wait_for_grant; else next_state <= s_idle; end if; when s_wait_for_grant => if (dcs_bg = '1') then next_state <= s_grant; elsif (timeout = '1') then next_state <= s_error; else next_state <= s_wait_for_grant; end if; when s_grant => next_state <= s_idle; when s_error => next_state <= s_idle; when others => next_state <= s_idle; end case; end process p_next_state; -- purpose: set outputs of module and internal signals p_output: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt_en <= '0'; we_dcs_i <= '0'; pslverr <= '0'; pready <= '1'; elsif rising_edge(clk) then --defaults case current_state is when s_idle => pslverr <= '0'; timeout_cnt_en <= '0'; when s_wait_for_grant => when s_grant => we_dcs_i <= '0'; pready <= '1'; when s_error => pslverr <= '1'; pready <= '1'; timeout_cnt_en <= '0'; when others => --defaults end case; case next_state is when s_idle => pready <= '1'; when s_wait_for_grant => timeout_cnt_en <= '1'; pready <= '0'; when s_grant => timeout_cnt_en <= '0'; pready <= '1'; we_dcs_i <= pwrite; when others => end case; end if ; end process p_output; --purpose: resets p_reset : process(clk, reset_n) begin if (reset_n = '0') then global_reset <= '1'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '1'; fec_reset <= '1'; elsif rising_edge(clk) then global_reset <= '0'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '0'; fec_reset <= '0'; if (we_dcs_i = '1') then case (paddr(15 downto 0)) is when c_global_reset => global_reset <= '1'; when c_rcu_reset => rcu_reset <= '1'; when c_fec_reset => fec_reset <= '1'; when others => -- do nothing end case; end if; end if; end process p_reset; --Purpose: Set up bus interrupt p_bus_int: process (clk, reset_n, reset_from_siu) begin if( reset_n = '0' or reset_from_siu = '1') then dcs_bi <= '0'; elsif (rising_edge(clk)) then if(siu_bg = '0' or dcs_bg = '1') then --do not interrupt if we have grant dcs_bi <= '0'; elsif (paddr (15 downto 0) = c_arbiter_irq) then dcs_bi <= '1'; end if; end if; end process p_bus_int; end architecture arc; ------------------------------------------------------------------------------- -- Title : DCS interface Package -- Project : RCU DCS interface ------------------------------------------------------------------------------- -- File : $RCSfile: dcs_interface_pkg.vhd,v $ -- Last edited by : $Author: alme $ -- Last update : $Date: 2008/02/15 12:23:43 $ -- Current Revision : $Revision: 1.4 $ ------------------------------------------------------------------------------- -- Description : Constant and function library for RCU Trigger Receiver -- design ------------------------------------------------------------------------------- -- Revision History : -- http://portal1.ift.uib.no/cgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway, 2005 -- This file has been written by Johan Alme -- Johan.Alme@ift.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; package dcs_interface_pkg is -- address information (this should be moved to a global adress mapping definition file.) -- memory spaces. -- Safety module address. Always ack these. constant c_MSM_space : std_logic_vector(3 downto 0):=X"8"; -- Actel space should NEVER be acked constant c_Actel_space : std_logic_vector(3 downto 0):=X"B"; -- treat as normal except for the subadresses 0xA00 and 0xA01 that should not be acked. constant c_trigger_space : std_logic_vector(3 downto 0):=X"4"; -- sub adresses -- belongs to trigger space. The two addresses are defined on the DCS board and should not be acked. constant c_dcsSetBunchReset : std_logic_vector(11 downto 0):= X"A00"; constant c_dcsSetEventReset : std_logic_vector(11 downto 0):= X"A01"; constant c_global_reset : std_logic_vector(15 downto 0):= X"5300"; constant c_fec_reset : std_logic_vector(15 downto 0):= X"5301"; constant c_rcu_reset : std_logic_vector(15 downto 0):= X"5302"; constant c_arbiter_irq : std_logic_vector(15 downto 0):= X"5310"; -- interrupts SIU grant constant c_grant : std_logic_vector(15 downto 0):= X"5311"; -- grant information given --Constant defining mem mapped mode on which the interface should be active constant c_memMappedMode0 : std_logic_vector(1 downto 0) := "00"; constant c_memMappedMode1 : std_logic_vector(1 downto 0) := "11"; end package dcs_interface_pkg; -------------------------------------------------------------------------------- -- Company: University of Bergen -- -- File: DCS_test.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- Component used to test functionality of apb_to_dcs bridge -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: Christian Torgersen -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity DCS_test is port ( clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity global_reset : in std_logic; -- global reset, positive polarity rcu_reset : in std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : in std_logic; -- reset for FEC, positive polarity we_dcs : in std_logic; -- write enable to the internal modules dcs_busBadd : in std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : in std_logic; -- interrupt in case DCS needs bus dcs_bg : out std_logic; -- dcs bus grant from arbiter dcs_br : in std_logic; -- dcs bus request to arbiter siu_bg : out std_logic -- siu bus grant from arbiter ); end DCS_test; architecture arch of DCS_test is -- signal, component etc. declarations signal data_outs :std_logic_vector(31 DOWNTO 0); signal wr_enable, rd_enable : std_logic; component mtest port( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end component; begin mtest_map: mtest port map( clk => clk, nreset => reset_n, wr_en => wr_enable, rd_en => rd_enable, address => dcs_busBadd(7 downto 0), data_in => dcs_busBdata_in, data_out => dcs_busBdata_out ); --dcs_busBdata_out <= data_outs; siu_bg <= '0'; rd_enable <= not(we_dcs); wr_enable <= we_dcs; -- to be used if checking two cycle read/write: --dcs_bg <= '1'; -- Used to test arbitration and wait states: p_arbitration: process (clk, reset_n) begin if reset_n = '0' then dcs_bg <= '1'; data_outs <= (others => '0'); elsif rising_edge(clk) then if (dcs_br = '1') then dcs_bg <= '1'; else dcs_bg<= '0'; end if; end if; end process p_arbitration; end arch; -------------------------------------------------------------------------------- -- Company: <Name> -- -- File: mtest.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- <Description here> -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: <Name> -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use ieee.numeric_std.all; entity mtest is port ( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end mtest; architecture arch of mtest is -- signal, component etc. declarations type memory IS ARRAY (0 TO 31) of std_logic_vector(31 DOWNTO 0); --type memory IS ARRAY (31 DOWNTO 0) of std_logic_vector; signal myram: memory; --attribute ram_init_file: STRING; --attribute ram_init_file OF myram: SIGNAL IS "ram_contents.mif"; begin -- generation of data_out process(clk,nreset) begin if (nreset='0') then data_out <= x"0000_0000"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- data_out <= x"0000_0000"; -- elsif(rd_en='1') then if(rd_en='1') then data_out <= myram(to_integer(unsigned(address))); end if; end if; end process; -- writing data to memory process(clk,nreset) begin if (nreset='0') then myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; -- elsif(wr_en='1') then if (wr_en='1') then myram(to_integer(unsigned(address))) <= data_in; end if; end if; end process; end arch; [[Category:Mikroelektronikk]] f4593c6e108d9facab7deb4816361e9a713aaa06 1961 1960 2013-09-30T09:13:38Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files which are included at the bottom of the page. Save the files with the names specified in the text. The files can be included by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). Copy the following to the User.bfm in your project, located under ''Files'' and ''simulation''. #=========================================================== # Enter your BFM commands in this file. # # Syntax: # ------- # # memmap resource_name base_address; # # write width resource_name byte_offset data; # read width resource_name byte_offset; # readcheck width resource_name byte_offset data; # #=========================================================== #include "subsystem.bfm" procedure user_main; # perform subsystem initialization routine # call subsystem_init; # add your BFM commands below: memmap apb_to_dcs_0 0x50000000; write w apb_to_dcs_0 0x0 0x12345678; write w apb_to_dcs_0 0x4 0xBEEFFACE; write w apb_to_dcs_0 0x8 0xABCDEF12; write w apb_to_dcs_0 0xC 0x44556622; readcheck w apb_to_dcs_0 0x0 0x12345678; readcheck w apb_to_dcs_0 0x4 0xBEEFFACE; readcheck w apb_to_dcs_0 0x8 0xABCDEF12; readcheck w apb_to_dcs_0 0xC 0x44556622; write w apb_to_dcs_0 0x10 0x98765432; write w apb_to_dcs_0 0x14 0xABBABABE; write w apb_to_dcs_0 0x18 0x12345ABC; write w apb_to_dcs_0 0x1C 0xDEADBEEF; readcheck w apb_to_dcs_0 0x10 0x98765432; readcheck w apb_to_dcs_0 0x14 0xABBABABE; readcheck w apb_to_dcs_0 0x18 0x12345ABC; readcheck w apb_to_dcs_0 0x1C 0xDEADBEEF; return Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> ------------------------------------------------------------------------------- -- Title : APB_to_DCS -- Project : RCU2 ------------------------------------------------------------------------------- -- File : apb_to_dcs.vhd -- Last edited by : Christian Torgersen -- Last update : 30.09.2013 - 09:26 -- Current Revision : 1.0 ------------------------------------------------------------------------------- -- Description : Mapping between AMBA APB and DCS bus. ------------------------------------------------------------------------------- -- Revision History : ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway -- This file has been written by Christian Torgersen -- Christian.torgersen@student.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; library work; use work.dcs_interface_pkg.all; entity apb_to_dcs is port( --APB input control signals penable : in std_logic; -- APB enable signal. Asserted high on second pulse psel : in std_logic; -- APB slave select from master pwrite : in std_logic; -- APB direction setting --APB input and addr paddr : in std_logic_vector(31 downto 0); -- APB address pwdata : in std_logic_vector(31 downto 0); -- APB write data --APB output signals prdata : out std_logic_vector(31 downto 0); -- APB read data pready : out std_logic; -- APB hold signal, for read/write more than 2 cycles pslverr : out std_logic; -- APB slave error signal clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity reset_from_siu : in std_logic; -- asynch reset from SIU, positive polarity --internal resets global_reset : out std_logic; -- global reset, positive polarity rcu_reset : out std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : out std_logic; -- reset for FEC, positive polarity --DCS bus signals we_dcs : out std_logic; -- write enable to the internal modules dcs_busBadd : out std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : out std_logic; -- interrupt in case DCS needs bus dcs_bg : in std_logic; -- dcs bus grant from arbiter dcs_br : out std_logic; -- dcs bus request to arbiter siu_bg : in std_logic -- siu bus grant from arbiter ); end apb_to_dcs; architecture arc of apb_to_dcs is --signal declarations type state is (s_idle, s_wait_for_grant, s_grant, s_error); signal current_state, next_state : state; -- signal resetting : std_logic; -- high when the resetting addresses are received, only used by dcs_addr signal timeout :std_logic; signal timeout_cnt :std_logic_vector(6 downto 0); signal timeout_cnt_en :std_logic; signal we_dcs_i :std_logic; begin --combinatorics timeout <= timeout_cnt(6); we_dcs <= we_dcs_i; dcs_br <= '1' when (psel = '1'and (next_state = s_wait_for_grant or next_state = s_grant)) else '0'; dcs_busBadd <= paddr(15 downto 0); --linking between APB and dcs addresses dcs_busBdata_out <= pwdata when (pwrite='1' and dcs_bg= '1') else (others => '0'); -- APB to DCS data prdata <= dcs_busBdata_in when (pwrite ='0' and dcs_bg= '1') else (others => '0'); -- DCS to APB data -- purpose: timeout counter for transaction p_timeout_cnt: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt <= (others => '0'); elsif rising_edge(clk) then if (timeout_cnt_en = '1') then timeout_cnt <= timeout_cnt + 1; else timeout_cnt <= (others => '0'); end if; end if; end process p_timeout_cnt; -- purpose: state machine driver p_state_driver: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then current_state <= s_idle; elsif rising_edge(clk) then current_state <= next_state; end if; end process p_state_driver; --purpose: set next state p_next_state: process(current_state, dcs_bg, timeout, psel, penable) begin case current_state is when s_idle => if (dcs_bg = '1' and psel = '1' and penable = '0') then -- giving two cycle read/write possibility next_state <= s_grant; elsif (dcs_bg = '0' and psel = '1' and penable = '0') then --Three or more cycle read/write next_state <= s_wait_for_grant; else next_state <= s_idle; end if; when s_wait_for_grant => if (dcs_bg = '1') then next_state <= s_grant; elsif (timeout = '1') then next_state <= s_error; else next_state <= s_wait_for_grant; end if; when s_grant => next_state <= s_idle; when s_error => next_state <= s_idle; when others => next_state <= s_idle; end case; end process p_next_state; -- purpose: set outputs of module and internal signals p_output: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt_en <= '0'; we_dcs_i <= '0'; pslverr <= '0'; pready <= '1'; elsif rising_edge(clk) then --defaults case current_state is when s_idle => pslverr <= '0'; timeout_cnt_en <= '0'; when s_wait_for_grant => when s_grant => we_dcs_i <= '0'; pready <= '1'; when s_error => pslverr <= '1'; pready <= '1'; timeout_cnt_en <= '0'; when others => --defaults end case; case next_state is when s_idle => pready <= '1'; when s_wait_for_grant => timeout_cnt_en <= '1'; pready <= '0'; when s_grant => timeout_cnt_en <= '0'; pready <= '1'; we_dcs_i <= pwrite; when others => end case; end if ; end process p_output; --purpose: resets p_reset : process(clk, reset_n) begin if (reset_n = '0') then global_reset <= '1'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '1'; fec_reset <= '1'; elsif rising_edge(clk) then global_reset <= '0'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '0'; fec_reset <= '0'; if (we_dcs_i = '1') then case (paddr(15 downto 0)) is when c_global_reset => global_reset <= '1'; when c_rcu_reset => rcu_reset <= '1'; when c_fec_reset => fec_reset <= '1'; when others => -- do nothing end case; end if; end if; end process p_reset; --Purpose: Set up bus interrupt p_bus_int: process (clk, reset_n, reset_from_siu) begin if( reset_n = '0' or reset_from_siu = '1') then dcs_bi <= '0'; elsif (rising_edge(clk)) then if(siu_bg = '0' or dcs_bg = '1') then --do not interrupt if we have grant dcs_bi <= '0'; elsif (paddr (15 downto 0) = c_arbiter_irq) then dcs_bi <= '1'; end if; end if; end process p_bus_int; end architecture arc; ------------------------------------------------------------------------------- -- Title : DCS interface Package -- Project : RCU DCS interface ------------------------------------------------------------------------------- -- File : $RCSfile: dcs_interface_pkg.vhd,v $ -- Last edited by : $Author: alme $ -- Last update : $Date: 2008/02/15 12:23:43 $ -- Current Revision : $Revision: 1.4 $ ------------------------------------------------------------------------------- -- Description : Constant and function library for RCU Trigger Receiver -- design ------------------------------------------------------------------------------- -- Revision History : -- http://portal1.ift.uib.no/cgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway, 2005 -- This file has been written by Johan Alme -- Johan.Alme@ift.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; package dcs_interface_pkg is -- address information (this should be moved to a global adress mapping definition file.) -- memory spaces. -- Safety module address. Always ack these. constant c_MSM_space : std_logic_vector(3 downto 0):=X"8"; -- Actel space should NEVER be acked constant c_Actel_space : std_logic_vector(3 downto 0):=X"B"; -- treat as normal except for the subadresses 0xA00 and 0xA01 that should not be acked. constant c_trigger_space : std_logic_vector(3 downto 0):=X"4"; -- sub adresses -- belongs to trigger space. The two addresses are defined on the DCS board and should not be acked. constant c_dcsSetBunchReset : std_logic_vector(11 downto 0):= X"A00"; constant c_dcsSetEventReset : std_logic_vector(11 downto 0):= X"A01"; constant c_global_reset : std_logic_vector(15 downto 0):= X"5300"; constant c_fec_reset : std_logic_vector(15 downto 0):= X"5301"; constant c_rcu_reset : std_logic_vector(15 downto 0):= X"5302"; constant c_arbiter_irq : std_logic_vector(15 downto 0):= X"5310"; -- interrupts SIU grant constant c_grant : std_logic_vector(15 downto 0):= X"5311"; -- grant information given --Constant defining mem mapped mode on which the interface should be active constant c_memMappedMode0 : std_logic_vector(1 downto 0) := "00"; constant c_memMappedMode1 : std_logic_vector(1 downto 0) := "11"; end package dcs_interface_pkg; -------------------------------------------------------------------------------- -- Company: University of Bergen -- -- File: DCS_test.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- Component used to test functionality of apb_to_dcs bridge -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: Christian Torgersen -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity DCS_test is port ( clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity global_reset : in std_logic; -- global reset, positive polarity rcu_reset : in std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : in std_logic; -- reset for FEC, positive polarity we_dcs : in std_logic; -- write enable to the internal modules dcs_busBadd : in std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : in std_logic; -- interrupt in case DCS needs bus dcs_bg : out std_logic; -- dcs bus grant from arbiter dcs_br : in std_logic; -- dcs bus request to arbiter siu_bg : out std_logic -- siu bus grant from arbiter ); end DCS_test; architecture arch of DCS_test is -- signal, component etc. declarations signal data_outs :std_logic_vector(31 DOWNTO 0); signal wr_enable, rd_enable : std_logic; component mtest port( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end component; begin mtest_map: mtest port map( clk => clk, nreset => reset_n, wr_en => wr_enable, rd_en => rd_enable, address => dcs_busBadd(7 downto 0), data_in => dcs_busBdata_in, data_out => dcs_busBdata_out ); --dcs_busBdata_out <= data_outs; siu_bg <= '0'; rd_enable <= not(we_dcs); wr_enable <= we_dcs; -- to be used if checking two cycle read/write: --dcs_bg <= '1'; -- Used to test arbitration and wait states: p_arbitration: process (clk, reset_n) begin if reset_n = '0' then dcs_bg <= '1'; data_outs <= (others => '0'); elsif rising_edge(clk) then if (dcs_br = '1') then dcs_bg <= '1'; else dcs_bg<= '0'; end if; end if; end process p_arbitration; end arch; -------------------------------------------------------------------------------- -- Company: <Name> -- -- File: mtest.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- <Description here> -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: <Name> -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use ieee.numeric_std.all; entity mtest is port ( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end mtest; architecture arch of mtest is -- signal, component etc. declarations type memory IS ARRAY (0 TO 31) of std_logic_vector(31 DOWNTO 0); --type memory IS ARRAY (31 DOWNTO 0) of std_logic_vector; signal myram: memory; --attribute ram_init_file: STRING; --attribute ram_init_file OF myram: SIGNAL IS "ram_contents.mif"; begin -- generation of data_out process(clk,nreset) begin if (nreset='0') then data_out <= x"0000_0000"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- data_out <= x"0000_0000"; -- elsif(rd_en='1') then if(rd_en='1') then data_out <= myram(to_integer(unsigned(address))); end if; end if; end process; -- writing data to memory process(clk,nreset) begin if (nreset='0') then myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; -- elsif(wr_en='1') then if (wr_en='1') then myram(to_integer(unsigned(address))) <= data_in; end if; end if; end process; end arch; [[Category:Mikroelektronikk]] 3add844a8d06b9cdca9361a755bc24a74eab49f3 1962 1961 2013-09-30T09:14:13Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files which are included at the bottom of the page. Save the files with the names specified in the text. The files can be included by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). Copy the following to the User.bfm in your project, located under ''Files'' and ''simulation''. #=========================================================== # Enter your BFM commands in this file. # # Syntax: # ------- # # memmap resource_name base_address; # # write width resource_name byte_offset data; # read width resource_name byte_offset; # readcheck width resource_name byte_offset data; # #=========================================================== #include "subsystem.bfm" procedure user_main; # perform subsystem initialization routine # call subsystem_init; # add your BFM commands below: memmap apb_to_dcs_0 0x50000000; write w apb_to_dcs_0 0x0 0x12345678; write w apb_to_dcs_0 0x4 0xBEEFFACE; write w apb_to_dcs_0 0x8 0xABCDEF12; write w apb_to_dcs_0 0xC 0x44556622; readcheck w apb_to_dcs_0 0x0 0x12345678; readcheck w apb_to_dcs_0 0x4 0xBEEFFACE; readcheck w apb_to_dcs_0 0x8 0xABCDEF12; readcheck w apb_to_dcs_0 0xC 0x44556622; write w apb_to_dcs_0 0x10 0x98765432; write w apb_to_dcs_0 0x14 0xABBABABE; write w apb_to_dcs_0 0x18 0x12345ABC; write w apb_to_dcs_0 0x1C 0xDEADBEEF; readcheck w apb_to_dcs_0 0x10 0x98765432; readcheck w apb_to_dcs_0 0x14 0xABBABABE; readcheck w apb_to_dcs_0 0x18 0x12345ABC; readcheck w apb_to_dcs_0 0x1C 0xDEADBEEF; return Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied in the .zip. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file, Fabric_top.io, by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the main.c supplied in the .zip file. The application will then write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> ------------------------------------------------------------------------------- -- Title : APB_to_DCS -- Project : RCU2 ------------------------------------------------------------------------------- -- File : apb_to_dcs.vhd -- Last edited by : Christian Torgersen -- Last update : 30.09.2013 - 09:26 -- Current Revision : 1.0 ------------------------------------------------------------------------------- -- Description : Mapping between AMBA APB and DCS bus. ------------------------------------------------------------------------------- -- Revision History : ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway -- This file has been written by Christian Torgersen -- Christian.torgersen@student.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; library work; use work.dcs_interface_pkg.all; entity apb_to_dcs is port( --APB input control signals penable : in std_logic; -- APB enable signal. Asserted high on second pulse psel : in std_logic; -- APB slave select from master pwrite : in std_logic; -- APB direction setting --APB input and addr paddr : in std_logic_vector(31 downto 0); -- APB address pwdata : in std_logic_vector(31 downto 0); -- APB write data --APB output signals prdata : out std_logic_vector(31 downto 0); -- APB read data pready : out std_logic; -- APB hold signal, for read/write more than 2 cycles pslverr : out std_logic; -- APB slave error signal clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity reset_from_siu : in std_logic; -- asynch reset from SIU, positive polarity --internal resets global_reset : out std_logic; -- global reset, positive polarity rcu_reset : out std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : out std_logic; -- reset for FEC, positive polarity --DCS bus signals we_dcs : out std_logic; -- write enable to the internal modules dcs_busBadd : out std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : out std_logic; -- interrupt in case DCS needs bus dcs_bg : in std_logic; -- dcs bus grant from arbiter dcs_br : out std_logic; -- dcs bus request to arbiter siu_bg : in std_logic -- siu bus grant from arbiter ); end apb_to_dcs; architecture arc of apb_to_dcs is --signal declarations type state is (s_idle, s_wait_for_grant, s_grant, s_error); signal current_state, next_state : state; -- signal resetting : std_logic; -- high when the resetting addresses are received, only used by dcs_addr signal timeout :std_logic; signal timeout_cnt :std_logic_vector(6 downto 0); signal timeout_cnt_en :std_logic; signal we_dcs_i :std_logic; begin --combinatorics timeout <= timeout_cnt(6); we_dcs <= we_dcs_i; dcs_br <= '1' when (psel = '1'and (next_state = s_wait_for_grant or next_state = s_grant)) else '0'; dcs_busBadd <= paddr(15 downto 0); --linking between APB and dcs addresses dcs_busBdata_out <= pwdata when (pwrite='1' and dcs_bg= '1') else (others => '0'); -- APB to DCS data prdata <= dcs_busBdata_in when (pwrite ='0' and dcs_bg= '1') else (others => '0'); -- DCS to APB data -- purpose: timeout counter for transaction p_timeout_cnt: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt <= (others => '0'); elsif rising_edge(clk) then if (timeout_cnt_en = '1') then timeout_cnt <= timeout_cnt + 1; else timeout_cnt <= (others => '0'); end if; end if; end process p_timeout_cnt; -- purpose: state machine driver p_state_driver: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then current_state <= s_idle; elsif rising_edge(clk) then current_state <= next_state; end if; end process p_state_driver; --purpose: set next state p_next_state: process(current_state, dcs_bg, timeout, psel, penable) begin case current_state is when s_idle => if (dcs_bg = '1' and psel = '1' and penable = '0') then -- giving two cycle read/write possibility next_state <= s_grant; elsif (dcs_bg = '0' and psel = '1' and penable = '0') then --Three or more cycle read/write next_state <= s_wait_for_grant; else next_state <= s_idle; end if; when s_wait_for_grant => if (dcs_bg = '1') then next_state <= s_grant; elsif (timeout = '1') then next_state <= s_error; else next_state <= s_wait_for_grant; end if; when s_grant => next_state <= s_idle; when s_error => next_state <= s_idle; when others => next_state <= s_idle; end case; end process p_next_state; -- purpose: set outputs of module and internal signals p_output: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt_en <= '0'; we_dcs_i <= '0'; pslverr <= '0'; pready <= '1'; elsif rising_edge(clk) then --defaults case current_state is when s_idle => pslverr <= '0'; timeout_cnt_en <= '0'; when s_wait_for_grant => when s_grant => we_dcs_i <= '0'; pready <= '1'; when s_error => pslverr <= '1'; pready <= '1'; timeout_cnt_en <= '0'; when others => --defaults end case; case next_state is when s_idle => pready <= '1'; when s_wait_for_grant => timeout_cnt_en <= '1'; pready <= '0'; when s_grant => timeout_cnt_en <= '0'; pready <= '1'; we_dcs_i <= pwrite; when others => end case; end if ; end process p_output; --purpose: resets p_reset : process(clk, reset_n) begin if (reset_n = '0') then global_reset <= '1'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '1'; fec_reset <= '1'; elsif rising_edge(clk) then global_reset <= '0'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '0'; fec_reset <= '0'; if (we_dcs_i = '1') then case (paddr(15 downto 0)) is when c_global_reset => global_reset <= '1'; when c_rcu_reset => rcu_reset <= '1'; when c_fec_reset => fec_reset <= '1'; when others => -- do nothing end case; end if; end if; end process p_reset; --Purpose: Set up bus interrupt p_bus_int: process (clk, reset_n, reset_from_siu) begin if( reset_n = '0' or reset_from_siu = '1') then dcs_bi <= '0'; elsif (rising_edge(clk)) then if(siu_bg = '0' or dcs_bg = '1') then --do not interrupt if we have grant dcs_bi <= '0'; elsif (paddr (15 downto 0) = c_arbiter_irq) then dcs_bi <= '1'; end if; end if; end process p_bus_int; end architecture arc; ------------------------------------------------------------------------------- -- Title : DCS interface Package -- Project : RCU DCS interface ------------------------------------------------------------------------------- -- File : $RCSfile: dcs_interface_pkg.vhd,v $ -- Last edited by : $Author: alme $ -- Last update : $Date: 2008/02/15 12:23:43 $ -- Current Revision : $Revision: 1.4 $ ------------------------------------------------------------------------------- -- Description : Constant and function library for RCU Trigger Receiver -- design ------------------------------------------------------------------------------- -- Revision History : -- http://portal1.ift.uib.no/cgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway, 2005 -- This file has been written by Johan Alme -- Johan.Alme@ift.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; package dcs_interface_pkg is -- address information (this should be moved to a global adress mapping definition file.) -- memory spaces. -- Safety module address. Always ack these. constant c_MSM_space : std_logic_vector(3 downto 0):=X"8"; -- Actel space should NEVER be acked constant c_Actel_space : std_logic_vector(3 downto 0):=X"B"; -- treat as normal except for the subadresses 0xA00 and 0xA01 that should not be acked. constant c_trigger_space : std_logic_vector(3 downto 0):=X"4"; -- sub adresses -- belongs to trigger space. The two addresses are defined on the DCS board and should not be acked. constant c_dcsSetBunchReset : std_logic_vector(11 downto 0):= X"A00"; constant c_dcsSetEventReset : std_logic_vector(11 downto 0):= X"A01"; constant c_global_reset : std_logic_vector(15 downto 0):= X"5300"; constant c_fec_reset : std_logic_vector(15 downto 0):= X"5301"; constant c_rcu_reset : std_logic_vector(15 downto 0):= X"5302"; constant c_arbiter_irq : std_logic_vector(15 downto 0):= X"5310"; -- interrupts SIU grant constant c_grant : std_logic_vector(15 downto 0):= X"5311"; -- grant information given --Constant defining mem mapped mode on which the interface should be active constant c_memMappedMode0 : std_logic_vector(1 downto 0) := "00"; constant c_memMappedMode1 : std_logic_vector(1 downto 0) := "11"; end package dcs_interface_pkg; -------------------------------------------------------------------------------- -- Company: University of Bergen -- -- File: DCS_test.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- Component used to test functionality of apb_to_dcs bridge -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: Christian Torgersen -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity DCS_test is port ( clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity global_reset : in std_logic; -- global reset, positive polarity rcu_reset : in std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : in std_logic; -- reset for FEC, positive polarity we_dcs : in std_logic; -- write enable to the internal modules dcs_busBadd : in std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : in std_logic; -- interrupt in case DCS needs bus dcs_bg : out std_logic; -- dcs bus grant from arbiter dcs_br : in std_logic; -- dcs bus request to arbiter siu_bg : out std_logic -- siu bus grant from arbiter ); end DCS_test; architecture arch of DCS_test is -- signal, component etc. declarations signal data_outs :std_logic_vector(31 DOWNTO 0); signal wr_enable, rd_enable : std_logic; component mtest port( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end component; begin mtest_map: mtest port map( clk => clk, nreset => reset_n, wr_en => wr_enable, rd_en => rd_enable, address => dcs_busBadd(7 downto 0), data_in => dcs_busBdata_in, data_out => dcs_busBdata_out ); --dcs_busBdata_out <= data_outs; siu_bg <= '0'; rd_enable <= not(we_dcs); wr_enable <= we_dcs; -- to be used if checking two cycle read/write: --dcs_bg <= '1'; -- Used to test arbitration and wait states: p_arbitration: process (clk, reset_n) begin if reset_n = '0' then dcs_bg <= '1'; data_outs <= (others => '0'); elsif rising_edge(clk) then if (dcs_br = '1') then dcs_bg <= '1'; else dcs_bg<= '0'; end if; end if; end process p_arbitration; end arch; -------------------------------------------------------------------------------- -- Company: <Name> -- -- File: mtest.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- <Description here> -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: <Name> -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use ieee.numeric_std.all; entity mtest is port ( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end mtest; architecture arch of mtest is -- signal, component etc. declarations type memory IS ARRAY (0 TO 31) of std_logic_vector(31 DOWNTO 0); --type memory IS ARRAY (31 DOWNTO 0) of std_logic_vector; signal myram: memory; --attribute ram_init_file: STRING; --attribute ram_init_file OF myram: SIGNAL IS "ram_contents.mif"; begin -- generation of data_out process(clk,nreset) begin if (nreset='0') then data_out <= x"0000_0000"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- data_out <= x"0000_0000"; -- elsif(rd_en='1') then if(rd_en='1') then data_out <= myram(to_integer(unsigned(address))); end if; end if; end process; -- writing data to memory process(clk,nreset) begin if (nreset='0') then myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; -- elsif(wr_en='1') then if (wr_en='1') then myram(to_integer(unsigned(address))) <= data_in; end if; end if; end process; end arch; [[Category:Mikroelektronikk]] 791677d0732faaaed6128ddba324c01238e3d180 1963 1962 2013-09-30T09:30:19Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files which are included at the bottom of the page. Save the files with the names specified in the text. The files can be included by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). Copy the following to the User.bfm in your project, located under ''Files'' and ''simulation''. #=========================================================== # Enter your BFM commands in this file. # # Syntax: # ------- # # memmap resource_name base_address; # # write width resource_name byte_offset data; # read width resource_name byte_offset; # readcheck width resource_name byte_offset data; # #=========================================================== #include "subsystem.bfm" procedure user_main; # perform subsystem initialization routine # call subsystem_init; # add your BFM commands below: memmap apb_to_dcs_0 0x50000000; write w apb_to_dcs_0 0x0 0x12345678; write w apb_to_dcs_0 0x4 0xBEEFFACE; write w apb_to_dcs_0 0x8 0xABCDEF12; write w apb_to_dcs_0 0xC 0x44556622; readcheck w apb_to_dcs_0 0x0 0x12345678; readcheck w apb_to_dcs_0 0x4 0xBEEFFACE; readcheck w apb_to_dcs_0 0x8 0xABCDEF12; readcheck w apb_to_dcs_0 0xC 0x44556622; write w apb_to_dcs_0 0x10 0x98765432; write w apb_to_dcs_0 0x14 0xABBABABE; write w apb_to_dcs_0 0x18 0x12345ABC; write w apb_to_dcs_0 0x1C 0xDEADBEEF; readcheck w apb_to_dcs_0 0x10 0x98765432; readcheck w apb_to_dcs_0 0x14 0xABBABABE; readcheck w apb_to_dcs_0 0x18 0x12345ABC; readcheck w apb_to_dcs_0 0x1C 0xDEADBEEF; return Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied below. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. quietly set ACTELLIBNAME SmartFusion2 quietly set PROJECT_DIR "C:/Microsemi/Projects/APB_custom_peripheral" source "${PROJECT_DIR}/simulation/CompileDssBfm.tcl";source "${PROJECT_DIR}/simulation/bfmtovec_compile.tcl"; if {[file exists presynth/_info]} { echo "INFO: Simulation library presynth already exists" } else { vlib presynth } vmap presynth presynth vmap SmartFusion2 "C:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" if {[file exists COREAPB3_LIB/_info]} { echo "INFO: Simulation library COREAPB3_LIB already exists" } else { vlib COREAPB3_LIB } vmap COREAPB3_LIB "COREAPB3_LIB" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral_MSS/APB_custom_peripheral_MSS.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/dcs_interface_pkg.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/apb_to_dcs.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/mtest.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/DCS_test.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/FCCC_0/APB_custom_peripheral_FCCC_0_FCCC.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/OSC_0/APB_custom_peripheral_OSC_0_OSC.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_muxptob3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_iaddr_reg.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/components.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/APB_custom_peripheral.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/testbench.vhd" vsim -L SmartFusion2 -L presynth -L COREAPB3_LIB -t 1fs presynth.testbench add wave \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PREADY \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSLVERR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE_PLL_LOCK \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_F2M \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PADDR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PENABLE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSEL \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PRDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWRITE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_M2F add wave \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/penable \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/psel \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwrite \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/paddr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/prdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pslverr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/clk \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_n \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_from_siu \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/global_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/rcu_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/fec_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pready \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/siu_bg add wave \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/siu_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/wr_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/rd_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/address \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/myram run 150 us Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file supplied below. Name it Fabric_top.io. # Microsemi I/O Physical Design Constraints file # Auto Generated User I/O Constraints file # Version: v11.1 11.1.0.14 # Family: SmartFusion2 , Die: M2S050T_ES , Package: 896 FBGA # Date generated: Fri Sep 20 10:03:27 2013 # # User Locked I/O Bank Settings # set_iobank Bank0 -vcci 1.80 -fixed yes set_iobank Bank1 -vcci 3.30 -fixed yes set_iobank Bank2 -vcci 3.30 -fixed yes set_iobank Bank3 -vcci 3.30 -fixed yes set_iobank Bank4 -vcci 3.30 -fixed yes set_iobank Bank8 -vcci 3.30 -fixed yes # # Unlocked I/O Bank Settings # The I/O Bank Settings can be locked by directly editing this file # or by making changes in the I/O Attribute Editor # # # User Locked I/O settings # set_io MMUART_0_RXD -pinname L23 -fixed yes set_io MMUART_0_TXD -pinname H27 -fixed yes set_io MSS_RESET_N_F2M \ -pinname F30 \ -fixed yes \ -RES_PULL Up \ -DIRECTION INPUT set_io GPIO_0_M2F \ -pinname G30 \ -fixed yes \ -DIRECTION OUTPUT The file is imported by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the following: #include "unistd.h" #include <stdio.h> #include "drivers/mss_uart/mss_uart.h" #include "drivers/mss_gpio/mss_gpio.h" //Initialize registers to read/write #define APB_TO_DCS_0 0x50000000U #define MEM1 (*(volatile int32_t *) 0x50000000) #define MEM2 (*(volatile int32_t *) 0x50000004) #define MEM3 (*(volatile int32_t *) 0x50000008) #define MEM4 (*(volatile int32_t *) 0x5000000C) #define MEM5 (*(volatile int32_t *) 0x50000010) #define MEM6 (*(volatile int32_t *) 0x50000014) #define MEM7 (*(volatile int32_t *) 0x50000018) #define MEM8 (*(volatile int32_t *) 0x5000001C) //Define a constant delay value #define DELAY_LOAD_VALUE 0x00080000 //about half a second int main() { /* * Initialize MSS GPIOs. */ MSS_GPIO_init(); /* * Configure MSS GPIO pin */ MSS_GPIO_config( MSS_GPIO_0 , MSS_GPIO_OUTPUT_MODE ); /* * Set initial state of GPIO pin */ MSS_GPIO_set_output(MSS_GPIO_0,0); //Using UART 0 mss_uart_instance_t * const gp_my_uart = &g_mss_uart0; /* * Using one delay to write and one delay to read */ volatile int32_t delay_count_1 = 0; volatile int32_t delay_count_2 = 0; delay_count_1 = DELAY_LOAD_VALUE/2; delay_count_2 = DELAY_LOAD_VALUE; /* * Variable to read value from memory to set led */ uint8_t led; /* * Incrementing value to be written to memory */ int32_t i = 0; /* * Variables to hold values read from memory */ int32_t m1,m2,m3,m4,m5,m6,m7,m8; /* * data to be sent on UART, holding chopped memory data */ uint8_t data[4]; /*-------------------------------------------------------------------------- * Initialize and configure UART. */ MSS_UART_init(gp_my_uart, MSS_UART_57600_BAUD, MSS_UART_DATA_8_BITS | MSS_UART_NO_PARITY | MSS_UART_ONE_STOP_BIT); MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r*******************Hello World*********************\n\r"); //Always while( 1 ) { -- delay_count_1; -- delay_count_2; /* * Updating memory values */ if (delay_count_1 <= 0) { delay_count_1 = DELAY_LOAD_VALUE; MEM1 = i; MEM2 = i+1; MEM3 = i+2; MEM4 = i+3; MEM5 = i+4; MEM6 = i+5; MEM7 = i+6; MEM8 = i+7; } /* * Reading memory values */ if (delay_count_2 <= 0) { delay_count_2 = DELAY_LOAD_VALUE; m1 = MEM1; if(m1 != i) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 1 is different from expected! *****\n\r"); } /* * Chopping data from memory, sending it to UART. * Reading hex/binary values from console */ data[3] = m1; data[2] = m1 >>8; data[1] = m1 >>16; data[0] = m1 >>24; MSS_UART_polled_tx(gp_my_uart, data, sizeof(data)); m2 = MEM2; if(m2 != i+1) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 2 is different from expected! *****\n\r"); } m3 = MEM3; if(m3 != i+2) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 3 is different from expected! *****\n\r"); } m4 = MEM4; if(m4 != i+3) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 4 is different from expected! *****\n\r"); } m5 = MEM5; if(m5 != i+4) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 5 is different from expected! *****\n\r"); } m6 = MEM6; if(m6 != i+5) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 6 is different from expected! *****\n\r"); } m7 = MEM7; if(m7 != i+6) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 7 is different from expected! *****\n\r"); } m8 = MEM8; if(m8 != i+7) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 8 is different from expected! *****\n\r"); } /* * Read last bit of current value of m1 and set GPIO (led) according to the bit value * Bit should toggle for every read cycle */ led = m1 & 0x00000001; MSS_GPIO_set_output(MSS_GPIO_0,led); ++i; } } } The application will write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> ------------------------------------------------------------------------------- -- Title : APB_to_DCS -- Project : RCU2 ------------------------------------------------------------------------------- -- File : apb_to_dcs.vhd -- Last edited by : Christian Torgersen -- Last update : 30.09.2013 - 09:26 -- Current Revision : 1.0 ------------------------------------------------------------------------------- -- Description : Mapping between AMBA APB and DCS bus. ------------------------------------------------------------------------------- -- Revision History : ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway -- This file has been written by Christian Torgersen -- Christian.torgersen@student.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; library work; use work.dcs_interface_pkg.all; entity apb_to_dcs is port( --APB input control signals penable : in std_logic; -- APB enable signal. Asserted high on second pulse psel : in std_logic; -- APB slave select from master pwrite : in std_logic; -- APB direction setting --APB input and addr paddr : in std_logic_vector(31 downto 0); -- APB address pwdata : in std_logic_vector(31 downto 0); -- APB write data --APB output signals prdata : out std_logic_vector(31 downto 0); -- APB read data pready : out std_logic; -- APB hold signal, for read/write more than 2 cycles pslverr : out std_logic; -- APB slave error signal clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity reset_from_siu : in std_logic; -- asynch reset from SIU, positive polarity --internal resets global_reset : out std_logic; -- global reset, positive polarity rcu_reset : out std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : out std_logic; -- reset for FEC, positive polarity --DCS bus signals we_dcs : out std_logic; -- write enable to the internal modules dcs_busBadd : out std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : out std_logic; -- interrupt in case DCS needs bus dcs_bg : in std_logic; -- dcs bus grant from arbiter dcs_br : out std_logic; -- dcs bus request to arbiter siu_bg : in std_logic -- siu bus grant from arbiter ); end apb_to_dcs; architecture arc of apb_to_dcs is --signal declarations type state is (s_idle, s_wait_for_grant, s_grant, s_error); signal current_state, next_state : state; -- signal resetting : std_logic; -- high when the resetting addresses are received, only used by dcs_addr signal timeout :std_logic; signal timeout_cnt :std_logic_vector(6 downto 0); signal timeout_cnt_en :std_logic; signal we_dcs_i :std_logic; begin --combinatorics timeout <= timeout_cnt(6); we_dcs <= we_dcs_i; dcs_br <= '1' when (psel = '1'and (next_state = s_wait_for_grant or next_state = s_grant)) else '0'; dcs_busBadd <= paddr(15 downto 0); --linking between APB and dcs addresses dcs_busBdata_out <= pwdata when (pwrite='1' and dcs_bg= '1') else (others => '0'); -- APB to DCS data prdata <= dcs_busBdata_in when (pwrite ='0' and dcs_bg= '1') else (others => '0'); -- DCS to APB data -- purpose: timeout counter for transaction p_timeout_cnt: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt <= (others => '0'); elsif rising_edge(clk) then if (timeout_cnt_en = '1') then timeout_cnt <= timeout_cnt + 1; else timeout_cnt <= (others => '0'); end if; end if; end process p_timeout_cnt; -- purpose: state machine driver p_state_driver: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then current_state <= s_idle; elsif rising_edge(clk) then current_state <= next_state; end if; end process p_state_driver; --purpose: set next state p_next_state: process(current_state, dcs_bg, timeout, psel, penable) begin case current_state is when s_idle => if (dcs_bg = '1' and psel = '1' and penable = '0') then -- giving two cycle read/write possibility next_state <= s_grant; elsif (dcs_bg = '0' and psel = '1' and penable = '0') then --Three or more cycle read/write next_state <= s_wait_for_grant; else next_state <= s_idle; end if; when s_wait_for_grant => if (dcs_bg = '1') then next_state <= s_grant; elsif (timeout = '1') then next_state <= s_error; else next_state <= s_wait_for_grant; end if; when s_grant => next_state <= s_idle; when s_error => next_state <= s_idle; when others => next_state <= s_idle; end case; end process p_next_state; -- purpose: set outputs of module and internal signals p_output: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt_en <= '0'; we_dcs_i <= '0'; pslverr <= '0'; pready <= '1'; elsif rising_edge(clk) then --defaults case current_state is when s_idle => pslverr <= '0'; timeout_cnt_en <= '0'; when s_wait_for_grant => when s_grant => we_dcs_i <= '0'; pready <= '1'; when s_error => pslverr <= '1'; pready <= '1'; timeout_cnt_en <= '0'; when others => --defaults end case; case next_state is when s_idle => pready <= '1'; when s_wait_for_grant => timeout_cnt_en <= '1'; pready <= '0'; when s_grant => timeout_cnt_en <= '0'; pready <= '1'; we_dcs_i <= pwrite; when others => end case; end if ; end process p_output; --purpose: resets p_reset : process(clk, reset_n) begin if (reset_n = '0') then global_reset <= '1'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '1'; fec_reset <= '1'; elsif rising_edge(clk) then global_reset <= '0'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '0'; fec_reset <= '0'; if (we_dcs_i = '1') then case (paddr(15 downto 0)) is when c_global_reset => global_reset <= '1'; when c_rcu_reset => rcu_reset <= '1'; when c_fec_reset => fec_reset <= '1'; when others => -- do nothing end case; end if; end if; end process p_reset; --Purpose: Set up bus interrupt p_bus_int: process (clk, reset_n, reset_from_siu) begin if( reset_n = '0' or reset_from_siu = '1') then dcs_bi <= '0'; elsif (rising_edge(clk)) then if(siu_bg = '0' or dcs_bg = '1') then --do not interrupt if we have grant dcs_bi <= '0'; elsif (paddr (15 downto 0) = c_arbiter_irq) then dcs_bi <= '1'; end if; end if; end process p_bus_int; end architecture arc; ------------------------------------------------------------------------------- -- Title : DCS interface Package -- Project : RCU DCS interface ------------------------------------------------------------------------------- -- File : $RCSfile: dcs_interface_pkg.vhd,v $ -- Last edited by : $Author: alme $ -- Last update : $Date: 2008/02/15 12:23:43 $ -- Current Revision : $Revision: 1.4 $ ------------------------------------------------------------------------------- -- Description : Constant and function library for RCU Trigger Receiver -- design ------------------------------------------------------------------------------- -- Revision History : -- http://portal1.ift.uib.no/cgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway, 2005 -- This file has been written by Johan Alme -- Johan.Alme@ift.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; package dcs_interface_pkg is -- address information (this should be moved to a global adress mapping definition file.) -- memory spaces. -- Safety module address. Always ack these. constant c_MSM_space : std_logic_vector(3 downto 0):=X"8"; -- Actel space should NEVER be acked constant c_Actel_space : std_logic_vector(3 downto 0):=X"B"; -- treat as normal except for the subadresses 0xA00 and 0xA01 that should not be acked. constant c_trigger_space : std_logic_vector(3 downto 0):=X"4"; -- sub adresses -- belongs to trigger space. The two addresses are defined on the DCS board and should not be acked. constant c_dcsSetBunchReset : std_logic_vector(11 downto 0):= X"A00"; constant c_dcsSetEventReset : std_logic_vector(11 downto 0):= X"A01"; constant c_global_reset : std_logic_vector(15 downto 0):= X"5300"; constant c_fec_reset : std_logic_vector(15 downto 0):= X"5301"; constant c_rcu_reset : std_logic_vector(15 downto 0):= X"5302"; constant c_arbiter_irq : std_logic_vector(15 downto 0):= X"5310"; -- interrupts SIU grant constant c_grant : std_logic_vector(15 downto 0):= X"5311"; -- grant information given --Constant defining mem mapped mode on which the interface should be active constant c_memMappedMode0 : std_logic_vector(1 downto 0) := "00"; constant c_memMappedMode1 : std_logic_vector(1 downto 0) := "11"; end package dcs_interface_pkg; -------------------------------------------------------------------------------- -- Company: University of Bergen -- -- File: DCS_test.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- Component used to test functionality of apb_to_dcs bridge -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: Christian Torgersen -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity DCS_test is port ( clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity global_reset : in std_logic; -- global reset, positive polarity rcu_reset : in std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : in std_logic; -- reset for FEC, positive polarity we_dcs : in std_logic; -- write enable to the internal modules dcs_busBadd : in std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : in std_logic; -- interrupt in case DCS needs bus dcs_bg : out std_logic; -- dcs bus grant from arbiter dcs_br : in std_logic; -- dcs bus request to arbiter siu_bg : out std_logic -- siu bus grant from arbiter ); end DCS_test; architecture arch of DCS_test is -- signal, component etc. declarations signal data_outs :std_logic_vector(31 DOWNTO 0); signal wr_enable, rd_enable : std_logic; component mtest port( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end component; begin mtest_map: mtest port map( clk => clk, nreset => reset_n, wr_en => wr_enable, rd_en => rd_enable, address => dcs_busBadd(7 downto 0), data_in => dcs_busBdata_in, data_out => dcs_busBdata_out ); --dcs_busBdata_out <= data_outs; siu_bg <= '0'; rd_enable <= not(we_dcs); wr_enable <= we_dcs; -- to be used if checking two cycle read/write: --dcs_bg <= '1'; -- Used to test arbitration and wait states: p_arbitration: process (clk, reset_n) begin if reset_n = '0' then dcs_bg <= '1'; data_outs <= (others => '0'); elsif rising_edge(clk) then if (dcs_br = '1') then dcs_bg <= '1'; else dcs_bg<= '0'; end if; end if; end process p_arbitration; end arch; -------------------------------------------------------------------------------- -- Company: <Name> -- -- File: mtest.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- <Description here> -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: <Name> -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use ieee.numeric_std.all; entity mtest is port ( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end mtest; architecture arch of mtest is -- signal, component etc. declarations type memory IS ARRAY (0 TO 31) of std_logic_vector(31 DOWNTO 0); --type memory IS ARRAY (31 DOWNTO 0) of std_logic_vector; signal myram: memory; --attribute ram_init_file: STRING; --attribute ram_init_file OF myram: SIGNAL IS "ram_contents.mif"; begin -- generation of data_out process(clk,nreset) begin if (nreset='0') then data_out <= x"0000_0000"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- data_out <= x"0000_0000"; -- elsif(rd_en='1') then if(rd_en='1') then data_out <= myram(to_integer(unsigned(address))); end if; end if; end process; -- writing data to memory process(clk,nreset) begin if (nreset='0') then myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; -- elsif(wr_en='1') then if (wr_en='1') then myram(to_integer(unsigned(address))) <= data_in; end if; end if; end process; end arch; [[Category:Mikroelektronikk]] 03632b6259722d494bed9a14aa517ff0c112aeb7 1964 1963 2013-09-30T09:32:32Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files which are included at the bottom of the page. Save the files with the names specified in the text. The files can be included by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). Copy the following to the User.bfm in your project, located under ''Files'' and ''simulation''. #=========================================================== # Enter your BFM commands in this file. # # Syntax: # ------- # # memmap resource_name base_address; # # write width resource_name byte_offset data; # read width resource_name byte_offset; # readcheck width resource_name byte_offset data; # #=========================================================== #include "subsystem.bfm" procedure user_main; # perform subsystem initialization routine # call subsystem_init; # add your BFM commands below: memmap apb_to_dcs_0 0x50000000; write w apb_to_dcs_0 0x0 0x12345678; write w apb_to_dcs_0 0x4 0xBEEFFACE; write w apb_to_dcs_0 0x8 0xABCDEF12; write w apb_to_dcs_0 0xC 0x44556622; readcheck w apb_to_dcs_0 0x0 0x12345678; readcheck w apb_to_dcs_0 0x4 0xBEEFFACE; readcheck w apb_to_dcs_0 0x8 0xABCDEF12; readcheck w apb_to_dcs_0 0xC 0x44556622; write w apb_to_dcs_0 0x10 0x98765432; write w apb_to_dcs_0 0x14 0xABBABABE; write w apb_to_dcs_0 0x18 0x12345ABC; write w apb_to_dcs_0 0x1C 0xDEADBEEF; readcheck w apb_to_dcs_0 0x10 0x98765432; readcheck w apb_to_dcs_0 0x14 0xABBABABE; readcheck w apb_to_dcs_0 0x18 0x12345ABC; readcheck w apb_to_dcs_0 0x1C 0xDEADBEEF; return Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied below. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. quietly set ACTELLIBNAME SmartFusion2 quietly set PROJECT_DIR "C:/Microsemi/Projects/APB_custom_peripheral" source "${PROJECT_DIR}/simulation/CompileDssBfm.tcl";source "${PROJECT_DIR}/simulation/bfmtovec_compile.tcl"; if {[file exists presynth/_info]} { echo "INFO: Simulation library presynth already exists" } else { vlib presynth } vmap presynth presynth vmap SmartFusion2 "C:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" if {[file exists COREAPB3_LIB/_info]} { echo "INFO: Simulation library COREAPB3_LIB already exists" } else { vlib COREAPB3_LIB } vmap COREAPB3_LIB "COREAPB3_LIB" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral_MSS/APB_custom_peripheral_MSS.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/dcs_interface_pkg.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/apb_to_dcs.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/mtest.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/DCS_test.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/FCCC_0/APB_custom_peripheral_FCCC_0_FCCC.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/OSC_0/APB_custom_peripheral_OSC_0_OSC.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_muxptob3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_iaddr_reg.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/components.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/APB_custom_peripheral.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/testbench.vhd" vsim -L SmartFusion2 -L presynth -L COREAPB3_LIB -t 1fs presynth.testbench add wave \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PREADY \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSLVERR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE_PLL_LOCK \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_F2M \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PADDR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PENABLE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSEL \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PRDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWRITE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_M2F add wave \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/penable \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/psel \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwrite \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/paddr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/prdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pslverr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/clk \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_n \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_from_siu \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/global_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/rcu_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/fec_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pready \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/siu_bg add wave \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/siu_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/wr_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/rd_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/address \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/myram run 150 us Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file supplied below. Name it Fabric_top.io. # Microsemi I/O Physical Design Constraints file # Auto Generated User I/O Constraints file # Version: v11.1 11.1.0.14 # Family: SmartFusion2 , Die: M2S050T_ES , Package: 896 FBGA # Date generated: Fri Sep 20 10:03:27 2013 # # User Locked I/O Bank Settings # set_iobank Bank0 -vcci 1.80 -fixed yes set_iobank Bank1 -vcci 3.30 -fixed yes set_iobank Bank2 -vcci 3.30 -fixed yes set_iobank Bank3 -vcci 3.30 -fixed yes set_iobank Bank4 -vcci 3.30 -fixed yes set_iobank Bank8 -vcci 3.30 -fixed yes # # Unlocked I/O Bank Settings # The I/O Bank Settings can be locked by directly editing this file # or by making changes in the I/O Attribute Editor # # # User Locked I/O settings # set_io MMUART_0_RXD -pinname L23 -fixed yes set_io MMUART_0_TXD -pinname H27 -fixed yes set_io MSS_RESET_N_F2M \ -pinname F30 \ -fixed yes \ -RES_PULL Up \ -DIRECTION INPUT set_io GPIO_0_M2F \ -pinname G30 \ -fixed yes \ -DIRECTION OUTPUT The file is imported by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the following: #include "unistd.h" #include <stdio.h> #include "drivers/mss_uart/mss_uart.h" #include "drivers/mss_gpio/mss_gpio.h" //Initialize registers to read/write #define APB_TO_DCS_0 0x50000000U #define MEM1 (*(volatile int32_t *) 0x50000000) #define MEM2 (*(volatile int32_t *) 0x50000004) #define MEM3 (*(volatile int32_t *) 0x50000008) #define MEM4 (*(volatile int32_t *) 0x5000000C) #define MEM5 (*(volatile int32_t *) 0x50000010) #define MEM6 (*(volatile int32_t *) 0x50000014) #define MEM7 (*(volatile int32_t *) 0x50000018) #define MEM8 (*(volatile int32_t *) 0x5000001C) //Define a constant delay value #define DELAY_LOAD_VALUE 0x00080000 //about half a second int main() { /* * Initialize MSS GPIOs. */ MSS_GPIO_init(); /* * Configure MSS GPIO pin */ MSS_GPIO_config( MSS_GPIO_0 , MSS_GPIO_OUTPUT_MODE ); /* * Set initial state of GPIO pin */ MSS_GPIO_set_output(MSS_GPIO_0,0); //Using UART 0 mss_uart_instance_t * const gp_my_uart = &g_mss_uart0; /* * Using one delay to write and one delay to read */ volatile int32_t delay_count_1 = 0; volatile int32_t delay_count_2 = 0; delay_count_1 = DELAY_LOAD_VALUE/2; delay_count_2 = DELAY_LOAD_VALUE; /* * Variable to read value from memory to set led */ uint8_t led; /* * Incrementing value to be written to memory */ int32_t i = 0; /* * Variables to hold values read from memory */ int32_t m1,m2,m3,m4,m5,m6,m7,m8; /* * data to be sent on UART, holding chopped memory data */ uint8_t data[4]; /*-------------------------------------------------------------------------- * Initialize and configure UART. */ MSS_UART_init(gp_my_uart, MSS_UART_57600_BAUD, MSS_UART_DATA_8_BITS | MSS_UART_NO_PARITY | MSS_UART_ONE_STOP_BIT); MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r*******************Hello World*********************\n\r"); //Always while( 1 ) { -- delay_count_1; -- delay_count_2; /* * Updating memory values */ if (delay_count_1 <= 0) { delay_count_1 = DELAY_LOAD_VALUE; MEM1 = i; MEM2 = i+1; MEM3 = i+2; MEM4 = i+3; MEM5 = i+4; MEM6 = i+5; MEM7 = i+6; MEM8 = i+7; } /* * Reading memory values */ if (delay_count_2 <= 0) { delay_count_2 = DELAY_LOAD_VALUE; m1 = MEM1; if(m1 != i) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 1 is different from expected! *****\n\r"); } /* * Chopping data from memory, sending it to UART. * Reading hex/binary values from console */ data[3] = m1; data[2] = m1 >>8; data[1] = m1 >>16; data[0] = m1 >>24; MSS_UART_polled_tx(gp_my_uart, data, sizeof(data)); m2 = MEM2; if(m2 != i+1) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 2 is different from expected! *****\n\r"); } m3 = MEM3; if(m3 != i+2) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 3 is different from expected! *****\n\r"); } m4 = MEM4; if(m4 != i+3) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 4 is different from expected! *****\n\r"); } m5 = MEM5; if(m5 != i+4) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 5 is different from expected! *****\n\r"); } m6 = MEM6; if(m6 != i+5) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 6 is different from expected! *****\n\r"); } m7 = MEM7; if(m7 != i+6) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 7 is different from expected! *****\n\r"); } m8 = MEM8; if(m8 != i+7) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 8 is different from expected! *****\n\r"); } /* * Read last bit of current value of m1 and set GPIO (led) according to the bit value * Bit should toggle for every read cycle */ led = m1 & 0x00000001; MSS_GPIO_set_output(MSS_GPIO_0,led); ++i; } } } The application will write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> =VHDL files= ------------------------------------------------------------------------------- -- Title : APB_to_DCS -- Project : RCU2 ------------------------------------------------------------------------------- -- File : apb_to_dcs.vhd -- Last edited by : Christian Torgersen -- Last update : 30.09.2013 - 09:26 -- Current Revision : 1.0 ------------------------------------------------------------------------------- -- Description : Mapping between AMBA APB and DCS bus. ------------------------------------------------------------------------------- -- Revision History : ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway -- This file has been written by Christian Torgersen -- Christian.torgersen@student.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; library work; use work.dcs_interface_pkg.all; entity apb_to_dcs is port( --APB input control signals penable : in std_logic; -- APB enable signal. Asserted high on second pulse psel : in std_logic; -- APB slave select from master pwrite : in std_logic; -- APB direction setting --APB input and addr paddr : in std_logic_vector(31 downto 0); -- APB address pwdata : in std_logic_vector(31 downto 0); -- APB write data --APB output signals prdata : out std_logic_vector(31 downto 0); -- APB read data pready : out std_logic; -- APB hold signal, for read/write more than 2 cycles pslverr : out std_logic; -- APB slave error signal clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity reset_from_siu : in std_logic; -- asynch reset from SIU, positive polarity --internal resets global_reset : out std_logic; -- global reset, positive polarity rcu_reset : out std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : out std_logic; -- reset for FEC, positive polarity --DCS bus signals we_dcs : out std_logic; -- write enable to the internal modules dcs_busBadd : out std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : out std_logic; -- interrupt in case DCS needs bus dcs_bg : in std_logic; -- dcs bus grant from arbiter dcs_br : out std_logic; -- dcs bus request to arbiter siu_bg : in std_logic -- siu bus grant from arbiter ); end apb_to_dcs; architecture arc of apb_to_dcs is --signal declarations type state is (s_idle, s_wait_for_grant, s_grant, s_error); signal current_state, next_state : state; -- signal resetting : std_logic; -- high when the resetting addresses are received, only used by dcs_addr signal timeout :std_logic; signal timeout_cnt :std_logic_vector(6 downto 0); signal timeout_cnt_en :std_logic; signal we_dcs_i :std_logic; begin --combinatorics timeout <= timeout_cnt(6); we_dcs <= we_dcs_i; dcs_br <= '1' when (psel = '1'and (next_state = s_wait_for_grant or next_state = s_grant)) else '0'; dcs_busBadd <= paddr(15 downto 0); --linking between APB and dcs addresses dcs_busBdata_out <= pwdata when (pwrite='1' and dcs_bg= '1') else (others => '0'); -- APB to DCS data prdata <= dcs_busBdata_in when (pwrite ='0' and dcs_bg= '1') else (others => '0'); -- DCS to APB data -- purpose: timeout counter for transaction p_timeout_cnt: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt <= (others => '0'); elsif rising_edge(clk) then if (timeout_cnt_en = '1') then timeout_cnt <= timeout_cnt + 1; else timeout_cnt <= (others => '0'); end if; end if; end process p_timeout_cnt; -- purpose: state machine driver p_state_driver: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then current_state <= s_idle; elsif rising_edge(clk) then current_state <= next_state; end if; end process p_state_driver; --purpose: set next state p_next_state: process(current_state, dcs_bg, timeout, psel, penable) begin case current_state is when s_idle => if (dcs_bg = '1' and psel = '1' and penable = '0') then -- giving two cycle read/write possibility next_state <= s_grant; elsif (dcs_bg = '0' and psel = '1' and penable = '0') then --Three or more cycle read/write next_state <= s_wait_for_grant; else next_state <= s_idle; end if; when s_wait_for_grant => if (dcs_bg = '1') then next_state <= s_grant; elsif (timeout = '1') then next_state <= s_error; else next_state <= s_wait_for_grant; end if; when s_grant => next_state <= s_idle; when s_error => next_state <= s_idle; when others => next_state <= s_idle; end case; end process p_next_state; -- purpose: set outputs of module and internal signals p_output: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt_en <= '0'; we_dcs_i <= '0'; pslverr <= '0'; pready <= '1'; elsif rising_edge(clk) then --defaults case current_state is when s_idle => pslverr <= '0'; timeout_cnt_en <= '0'; when s_wait_for_grant => when s_grant => we_dcs_i <= '0'; pready <= '1'; when s_error => pslverr <= '1'; pready <= '1'; timeout_cnt_en <= '0'; when others => --defaults end case; case next_state is when s_idle => pready <= '1'; when s_wait_for_grant => timeout_cnt_en <= '1'; pready <= '0'; when s_grant => timeout_cnt_en <= '0'; pready <= '1'; we_dcs_i <= pwrite; when others => end case; end if ; end process p_output; --purpose: resets p_reset : process(clk, reset_n) begin if (reset_n = '0') then global_reset <= '1'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '1'; fec_reset <= '1'; elsif rising_edge(clk) then global_reset <= '0'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '0'; fec_reset <= '0'; if (we_dcs_i = '1') then case (paddr(15 downto 0)) is when c_global_reset => global_reset <= '1'; when c_rcu_reset => rcu_reset <= '1'; when c_fec_reset => fec_reset <= '1'; when others => -- do nothing end case; end if; end if; end process p_reset; --Purpose: Set up bus interrupt p_bus_int: process (clk, reset_n, reset_from_siu) begin if( reset_n = '0' or reset_from_siu = '1') then dcs_bi <= '0'; elsif (rising_edge(clk)) then if(siu_bg = '0' or dcs_bg = '1') then --do not interrupt if we have grant dcs_bi <= '0'; elsif (paddr (15 downto 0) = c_arbiter_irq) then dcs_bi <= '1'; end if; end if; end process p_bus_int; end architecture arc; ------------------------------------------------------------------------------- -- Title : DCS interface Package -- Project : RCU DCS interface ------------------------------------------------------------------------------- -- File : $RCSfile: dcs_interface_pkg.vhd,v $ -- Last edited by : $Author: alme $ -- Last update : $Date: 2008/02/15 12:23:43 $ -- Current Revision : $Revision: 1.4 $ ------------------------------------------------------------------------------- -- Description : Constant and function library for RCU Trigger Receiver -- design ------------------------------------------------------------------------------- -- Revision History : -- http://portal1.ift.uib.no/cgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway, 2005 -- This file has been written by Johan Alme -- Johan.Alme@ift.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; package dcs_interface_pkg is -- address information (this should be moved to a global adress mapping definition file.) -- memory spaces. -- Safety module address. Always ack these. constant c_MSM_space : std_logic_vector(3 downto 0):=X"8"; -- Actel space should NEVER be acked constant c_Actel_space : std_logic_vector(3 downto 0):=X"B"; -- treat as normal except for the subadresses 0xA00 and 0xA01 that should not be acked. constant c_trigger_space : std_logic_vector(3 downto 0):=X"4"; -- sub adresses -- belongs to trigger space. The two addresses are defined on the DCS board and should not be acked. constant c_dcsSetBunchReset : std_logic_vector(11 downto 0):= X"A00"; constant c_dcsSetEventReset : std_logic_vector(11 downto 0):= X"A01"; constant c_global_reset : std_logic_vector(15 downto 0):= X"5300"; constant c_fec_reset : std_logic_vector(15 downto 0):= X"5301"; constant c_rcu_reset : std_logic_vector(15 downto 0):= X"5302"; constant c_arbiter_irq : std_logic_vector(15 downto 0):= X"5310"; -- interrupts SIU grant constant c_grant : std_logic_vector(15 downto 0):= X"5311"; -- grant information given --Constant defining mem mapped mode on which the interface should be active constant c_memMappedMode0 : std_logic_vector(1 downto 0) := "00"; constant c_memMappedMode1 : std_logic_vector(1 downto 0) := "11"; end package dcs_interface_pkg; -------------------------------------------------------------------------------- -- Company: University of Bergen -- -- File: DCS_test.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- Component used to test functionality of apb_to_dcs bridge -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: Christian Torgersen -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity DCS_test is port ( clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity global_reset : in std_logic; -- global reset, positive polarity rcu_reset : in std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : in std_logic; -- reset for FEC, positive polarity we_dcs : in std_logic; -- write enable to the internal modules dcs_busBadd : in std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : in std_logic; -- interrupt in case DCS needs bus dcs_bg : out std_logic; -- dcs bus grant from arbiter dcs_br : in std_logic; -- dcs bus request to arbiter siu_bg : out std_logic -- siu bus grant from arbiter ); end DCS_test; architecture arch of DCS_test is -- signal, component etc. declarations signal data_outs :std_logic_vector(31 DOWNTO 0); signal wr_enable, rd_enable : std_logic; component mtest port( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end component; begin mtest_map: mtest port map( clk => clk, nreset => reset_n, wr_en => wr_enable, rd_en => rd_enable, address => dcs_busBadd(7 downto 0), data_in => dcs_busBdata_in, data_out => dcs_busBdata_out ); --dcs_busBdata_out <= data_outs; siu_bg <= '0'; rd_enable <= not(we_dcs); wr_enable <= we_dcs; -- to be used if checking two cycle read/write: --dcs_bg <= '1'; -- Used to test arbitration and wait states: p_arbitration: process (clk, reset_n) begin if reset_n = '0' then dcs_bg <= '1'; data_outs <= (others => '0'); elsif rising_edge(clk) then if (dcs_br = '1') then dcs_bg <= '1'; else dcs_bg<= '0'; end if; end if; end process p_arbitration; end arch; -------------------------------------------------------------------------------- -- Company: <Name> -- -- File: mtest.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- <Description here> -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: <Name> -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use ieee.numeric_std.all; entity mtest is port ( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end mtest; architecture arch of mtest is -- signal, component etc. declarations type memory IS ARRAY (0 TO 31) of std_logic_vector(31 DOWNTO 0); --type memory IS ARRAY (31 DOWNTO 0) of std_logic_vector; signal myram: memory; --attribute ram_init_file: STRING; --attribute ram_init_file OF myram: SIGNAL IS "ram_contents.mif"; begin -- generation of data_out process(clk,nreset) begin if (nreset='0') then data_out <= x"0000_0000"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- data_out <= x"0000_0000"; -- elsif(rd_en='1') then if(rd_en='1') then data_out <= myram(to_integer(unsigned(address))); end if; end if; end process; -- writing data to memory process(clk,nreset) begin if (nreset='0') then myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; -- elsif(wr_en='1') then if (wr_en='1') then myram(to_integer(unsigned(address))) <= data_in; end if; end if; end process; end arch; [[Category:Mikroelektronikk]] 72ee44979ef309523e0f6670575a18febe7dd7a6 1978 1964 2013-10-22T11:21:22Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files which are included at the bottom of the page. Save the files with the names specified in the text. The files can be included by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). Copy the following to the User.bfm in your project, located under ''Files'' and ''simulation''. #=========================================================== # Enter your BFM commands in this file. # # Syntax: # ------- # # memmap resource_name base_address; # # write width resource_name byte_offset data; # read width resource_name byte_offset; # readcheck width resource_name byte_offset data; # #=========================================================== #include "subsystem.bfm" procedure user_main; # perform subsystem initialization routine # call subsystem_init; # add your BFM commands below: memmap apb_to_dcs_0 0x50000000; write w apb_to_dcs_0 0x0 0x12345678; write w apb_to_dcs_0 0x4 0xBEEFFACE; write w apb_to_dcs_0 0x8 0xABCDEF12; write w apb_to_dcs_0 0xC 0x44556622; readcheck w apb_to_dcs_0 0x0 0x12345678; readcheck w apb_to_dcs_0 0x4 0xBEEFFACE; readcheck w apb_to_dcs_0 0x8 0xABCDEF12; readcheck w apb_to_dcs_0 0xC 0x44556622; write w apb_to_dcs_0 0x10 0x98765432; write w apb_to_dcs_0 0x14 0xABBABABE; write w apb_to_dcs_0 0x18 0x12345ABC; write w apb_to_dcs_0 0x1C 0xDEADBEEF; readcheck w apb_to_dcs_0 0x10 0x98765432; readcheck w apb_to_dcs_0 0x14 0xABBABABE; readcheck w apb_to_dcs_0 0x18 0x12345ABC; readcheck w apb_to_dcs_0 0x1C 0xDEADBEEF; return Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied below. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. quietly set ACTELLIBNAME SmartFusion2 quietly set PROJECT_DIR "C:/Microsemi/Projects/APB_custom_peripheral" source "${PROJECT_DIR}/simulation/CompileDssBfm.tcl";source "${PROJECT_DIR}/simulation/bfmtovec_compile.tcl"; if {[file exists presynth/_info]} { echo "INFO: Simulation library presynth already exists" } else { vlib presynth } vmap presynth presynth vmap SmartFusion2 "C:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" if {[file exists COREAPB3_LIB/_info]} { echo "INFO: Simulation library COREAPB3_LIB already exists" } else { vlib COREAPB3_LIB } vmap COREAPB3_LIB "COREAPB3_LIB" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral_MSS/APB_custom_peripheral_MSS.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/dcs_interface_pkg.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/apb_to_dcs.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/mtest.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/DCS_test.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/FCCC_0/APB_custom_peripheral_FCCC_0_FCCC.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/OSC_0/APB_custom_peripheral_OSC_0_OSC.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_muxptob3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_iaddr_reg.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/components.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/APB_custom_peripheral.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/testbench.vhd" vsim -L SmartFusion2 -L presynth -L COREAPB3_LIB -t 1fs presynth.testbench add wave \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PREADY \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSLVERR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE_PLL_LOCK \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_F2M \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PADDR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PENABLE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSEL \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PRDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWRITE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_M2F add wave \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/penable \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/psel \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwrite \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/paddr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/prdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pslverr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/clk \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_n \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_from_siu \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/global_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/rcu_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/fec_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pready \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/siu_bg add wave \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/siu_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/wr_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/rd_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/address \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/myram run 150 us Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file supplied below. Name it Fabric_top.io. # Microsemi I/O Physical Design Constraints file # Auto Generated User I/O Constraints file # Version: v11.1 11.1.0.14 # Family: SmartFusion2 , Die: M2S050T_ES , Package: 896 FBGA # Date generated: Fri Sep 20 10:03:27 2013 # # User Locked I/O Bank Settings # set_iobank Bank0 -vcci 1.80 -fixed yes set_iobank Bank1 -vcci 3.30 -fixed yes set_iobank Bank2 -vcci 3.30 -fixed yes set_iobank Bank3 -vcci 3.30 -fixed yes set_iobank Bank4 -vcci 3.30 -fixed yes set_iobank Bank8 -vcci 3.30 -fixed yes # # Unlocked I/O Bank Settings # The I/O Bank Settings can be locked by directly editing this file # or by making changes in the I/O Attribute Editor # # # User Locked I/O settings # set_io MMUART_0_RXD -pinname L23 -fixed yes set_io MMUART_0_TXD -pinname H27 -fixed yes set_io MSS_RESET_N_F2M \ -pinname F30 \ -fixed yes \ -RES_PULL Up \ -DIRECTION INPUT set_io GPIO_0_M2F \ -pinname G30 \ -fixed yes \ -DIRECTION OUTPUT The file is imported by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the following: #include "unistd.h" #include <stdio.h> #include "drivers/mss_uart/mss_uart.h" #include "drivers/mss_gpio/mss_gpio.h" //Initialize registers to read/write #define APB_TO_DCS_0 0x50000000U #define MEM1 (*(volatile int32_t *) 0x50000000) #define MEM2 (*(volatile int32_t *) 0x50000004) #define MEM3 (*(volatile int32_t *) 0x50000008) #define MEM4 (*(volatile int32_t *) 0x5000000C) #define MEM5 (*(volatile int32_t *) 0x50000010) #define MEM6 (*(volatile int32_t *) 0x50000014) #define MEM7 (*(volatile int32_t *) 0x50000018) #define MEM8 (*(volatile int32_t *) 0x5000001C) //Define a constant delay value #define DELAY_LOAD_VALUE 0x00080000 //about half a second int main() { /* * Initialize MSS GPIOs. */ MSS_GPIO_init(); /* * Configure MSS GPIO pin */ MSS_GPIO_config( MSS_GPIO_0 , MSS_GPIO_OUTPUT_MODE ); /* * Set initial state of GPIO pin */ MSS_GPIO_set_output(MSS_GPIO_0,0); //Using UART 0 mss_uart_instance_t * const gp_my_uart = &g_mss_uart0; /* * Using one delay to write and one delay to read */ volatile int32_t delay_count_1 = 0; volatile int32_t delay_count_2 = 0; delay_count_1 = DELAY_LOAD_VALUE/2; delay_count_2 = DELAY_LOAD_VALUE; /* * Variable to read value from memory to set led */ uint8_t led; /* * Incrementing value to be written to memory */ int32_t i = 0; /* * Variables to hold values read from memory */ int32_t m1,m2,m3,m4,m5,m6,m7,m8; /* * data to be sent on UART, holding chopped memory data */ uint8_t data[4]; /*-------------------------------------------------------------------------- * Initialize and configure UART. */ MSS_UART_init(gp_my_uart, MSS_UART_57600_BAUD, MSS_UART_DATA_8_BITS | MSS_UART_NO_PARITY | MSS_UART_ONE_STOP_BIT); MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r*******************Hello World*********************\n\r"); //Always while( 1 ) { -- delay_count_1; -- delay_count_2; /* * Updating memory values */ if (delay_count_1 <= 0) { delay_count_1 = DELAY_LOAD_VALUE; MEM1 = i; MEM2 = i+1; MEM3 = i+2; MEM4 = i+3; MEM5 = i+4; MEM6 = i+5; MEM7 = i+6; MEM8 = i+7; } /* * Reading memory values */ if (delay_count_2 <= 0) { delay_count_2 = DELAY_LOAD_VALUE; m1 = MEM1; if(m1 != i) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 1 is different from expected! *****\n\r"); } /* * Chopping data from memory, sending it to UART. * Reading hex/binary values from console */ data[3] = m1; data[2] = m1 >>8; data[1] = m1 >>16; data[0] = m1 >>24; MSS_UART_polled_tx(gp_my_uart, data, sizeof(data)); m2 = MEM2; if(m2 != i+1) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 2 is different from expected! *****\n\r"); } m3 = MEM3; if(m3 != i+2) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 3 is different from expected! *****\n\r"); } m4 = MEM4; if(m4 != i+3) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 4 is different from expected! *****\n\r"); } m5 = MEM5; if(m5 != i+4) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 5 is different from expected! *****\n\r"); } m6 = MEM6; if(m6 != i+5) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 6 is different from expected! *****\n\r"); } m7 = MEM7; if(m7 != i+6) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 7 is different from expected! *****\n\r"); } m8 = MEM8; if(m8 != i+7) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 8 is different from expected! *****\n\r"); } /* * Read last bit of current value of m1 and set GPIO (led) according to the bit value * Bit should toggle for every read cycle */ led = m1 & 0x00000001; MSS_GPIO_set_output(MSS_GPIO_0,led); ++i; } } } The application will write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> =VHDL files= ------------------------------------------------------------------------------- -- Title : APB_to_DCS -- Project : RCU2 ------------------------------------------------------------------------------- -- File : apb_to_dcs.vhd -- Last edited by : Christian Torgersen -- Last update : 30.09.2013 - 09:26 -- Current Revision : 1.0 ------------------------------------------------------------------------------- -- Description : Mapping between AMBA APB and DCS bus. ------------------------------------------------------------------------------- -- Revision History : ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway -- This file has been written by Christian Torgersen -- Christian.torgersen@student.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; library work; use work.dcs_interface_pkg.all; entity apb_to_dcs is port( --APB input control signals penable : in std_logic; -- APB enable signal. Asserted high on second pulse psel : in std_logic; -- APB slave select from master pwrite : in std_logic; -- APB direction setting --APB input and addr paddr : in std_logic_vector(31 downto 0); -- APB address pwdata : in std_logic_vector(31 downto 0); -- APB write data --APB output signals prdata : out std_logic_vector(31 downto 0); -- APB read data pready : out std_logic; -- APB hold signal, for read/write more than 2 cycles pslverr : out std_logic; -- APB slave error signal clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity reset_from_siu : in std_logic; -- asynch reset from SIU, positive polarity --internal resets global_reset : out std_logic; -- global reset, positive polarity rcu_reset : out std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : out std_logic; -- reset for FEC, positive polarity --DCS bus signals we_dcs : out std_logic; -- write enable to the internal modules dcs_busBadd : out std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : out std_logic; -- interrupt in case DCS needs bus dcs_bg : in std_logic; -- dcs bus grant from arbiter dcs_br : out std_logic; -- dcs bus request to arbiter siu_bg : in std_logic -- siu bus grant from arbiter ); end apb_to_dcs; architecture arc of apb_to_dcs is --signal declarations type state is (s_idle, s_wait_for_grant, s_grant, s_error); signal current_state, next_state : state; -- signal resetting : std_logic; -- high when the resetting addresses are received, only used by dcs_addr signal timeout :std_logic; signal timeout_cnt :std_logic_vector(6 downto 0); signal timeout_cnt_en :std_logic; signal we_dcs_i :std_logic; begin --combinatorics timeout <= timeout_cnt(6); we_dcs <= we_dcs_i; dcs_br <= '1' when (psel = '1'and (next_state = s_wait_for_grant or next_state = s_grant)) else '0'; dcs_busBadd <= paddr(15 downto 0); --linking between APB and dcs addresses dcs_busBdata_out <= pwdata when (pwrite='1' and dcs_bg= '1') else (others => '0'); -- APB to DCS data prdata <= dcs_busBdata_in when (pwrite ='0' and dcs_bg= '1') else (others => '0'); -- DCS to APB data -- purpose: timeout counter for transaction p_timeout_cnt: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt <= (others => '0'); elsif rising_edge(clk) then if (timeout_cnt_en = '1') then timeout_cnt <= timeout_cnt + 1; else timeout_cnt <= (others => '0'); end if; end if; end process p_timeout_cnt; -- purpose: state machine driver p_state_driver: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then current_state <= s_idle; elsif rising_edge(clk) then current_state <= next_state; end if; end process p_state_driver; --purpose: set next state p_next_state: process(current_state, dcs_bg, timeout, psel, penable) begin case current_state is when s_idle => if (dcs_bg = '1' and psel = '1' and penable = '0') then -- giving two cycle read/write possibility next_state <= s_grant; elsif (dcs_bg = '0' and psel = '1' and penable = '0') then --Three or more cycle read/write next_state <= s_wait_for_grant; else next_state <= s_idle; end if; when s_wait_for_grant => if (dcs_bg = '1') then next_state <= s_grant; elsif (timeout = '1') then next_state <= s_error; else next_state <= s_wait_for_grant; end if; when s_grant => next_state <= s_idle; when s_error => next_state <= s_idle; when others => next_state <= s_idle; end case; end process p_next_state; -- purpose: set outputs of module and internal signals p_output: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt_en <= '0'; we_dcs_i <= '0'; pslverr <= '0'; pready <= '1'; elsif rising_edge(clk) then --defaults case current_state is when s_idle => pslverr <= '0'; timeout_cnt_en <= '0'; when s_wait_for_grant => when s_grant => we_dcs_i <= '0'; pready <= '1'; when s_error => pslverr <= '1'; pready <= '1'; timeout_cnt_en <= '0'; when others => --defaults end case; case next_state is when s_idle => pready <= '1'; when s_wait_for_grant => timeout_cnt_en <= '1'; pready <= '0'; when s_grant => timeout_cnt_en <= '0'; pready <= '1'; we_dcs_i <= pwrite; when others => end case; end if ; end process p_output; --purpose: resets p_reset : process(clk, reset_n) begin if (reset_n = '0') then global_reset <= '1'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '1'; fec_reset <= '1'; elsif rising_edge(clk) then global_reset <= '0'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '0'; fec_reset <= '0'; if (we_dcs_i = '1') then case (paddr(15 downto 0)) is when c_global_reset => global_reset <= '1'; when c_rcu_reset => rcu_reset <= '1'; when c_fec_reset => fec_reset <= '1'; when others => -- do nothing end case; end if; end if; end process p_reset; --Purpose: Set up bus interrupt p_bus_int: process (clk, reset_n, reset_from_siu) begin if( reset_n = '0' or reset_from_siu = '1') then dcs_bi <= '0'; elsif (rising_edge(clk)) then if(siu_bg = '0' or dcs_bg = '1') then --do not interrupt if we have grant dcs_bi <= '0'; elsif (paddr (15 downto 0) = c_arbiter_irq) then dcs_bi <= '1'; end if; end if; end process p_bus_int; end architecture arc; ------------------------------------------------------------------------------- -- Title : DCS interface Package -- Project : RCU DCS interface ------------------------------------------------------------------------------- -- File : $RCSfile: dcs_interface_pkg.vhd,v $ -- Last edited by : $Author: alme $ -- Last update : $Date: 2008/02/15 12:23:43 $ -- Current Revision : $Revision: 1.4 $ ------------------------------------------------------------------------------- -- Description : Constant and function library for RCU Trigger Receiver -- design ------------------------------------------------------------------------------- -- Revision History : -- http://portal1.ift.uib.no/cgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway, 2005 -- This file has been written by Johan Alme -- Johan.Alme@ift.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; package dcs_interface_pkg is -- address information (this should be moved to a global adress mapping definition file.) -- memory spaces. -- Safety module address. Always ack these. constant c_MSM_space : std_logic_vector(3 downto 0):=X"8"; -- Actel space should NEVER be acked constant c_Actel_space : std_logic_vector(3 downto 0):=X"B"; -- treat as normal except for the subadresses 0xA00 and 0xA01 that should not be acked. constant c_trigger_space : std_logic_vector(3 downto 0):=X"4"; -- sub adresses -- belongs to trigger space. The two addresses are defined on the DCS board and should not be acked. constant c_dcsSetBunchReset : std_logic_vector(11 downto 0):= X"A00"; constant c_dcsSetEventReset : std_logic_vector(11 downto 0):= X"A01"; constant c_global_reset : std_logic_vector(15 downto 0):= X"5300"; constant c_fec_reset : std_logic_vector(15 downto 0):= X"5301"; constant c_rcu_reset : std_logic_vector(15 downto 0):= X"5302"; constant c_arbiter_irq : std_logic_vector(15 downto 0):= X"5310"; -- interrupts SIU grant constant c_grant : std_logic_vector(15 downto 0):= X"5311"; -- grant information given --Constant defining mem mapped mode on which the interface should be active constant c_memMappedMode0 : std_logic_vector(1 downto 0) := "00"; constant c_memMappedMode1 : std_logic_vector(1 downto 0) := "11"; end package dcs_interface_pkg; -------------------------------------------------------------------------------- -- Company: University of Bergen -- -- File: DCS_test.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- Component used to test functionality of apb_to_dcs bridge -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: Christian Torgersen -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity DCS_test is port ( clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity global_reset : in std_logic; -- global reset, positive polarity rcu_reset : in std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : in std_logic; -- reset for FEC, positive polarity we_dcs : in std_logic; -- write enable to the internal modules dcs_busBadd : in std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : in std_logic; -- interrupt in case DCS needs bus dcs_bg : out std_logic; -- dcs bus grant from arbiter dcs_br : in std_logic; -- dcs bus request to arbiter siu_bg : out std_logic -- siu bus grant from arbiter ); end DCS_test; architecture arch of DCS_test is -- signal, component etc. declarations signal data_outs :std_logic_vector(31 DOWNTO 0); signal wr_enable, rd_enable : std_logic; component mtest port( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end component; begin mtest_map: mtest port map( clk => clk, nreset => reset_n, wr_en => wr_enable, rd_en => rd_enable, address => dcs_busBadd(7 downto 0), data_in => dcs_busBdata_in, data_out => dcs_busBdata_out ); --dcs_busBdata_out <= data_outs; siu_bg <= '0'; rd_enable <= not(we_dcs); wr_enable <= we_dcs; -- to be used if checking two cycle read/write: --dcs_bg <= '1'; -- Used to test arbitration and wait states: p_arbitration: process (clk, reset_n) begin if reset_n = '0' then dcs_bg <= '1'; data_outs <= (others => '0'); elsif rising_edge(clk) then if (dcs_br = '1') then dcs_bg <= '1'; else dcs_bg<= '0'; end if; end if; end process p_arbitration; end arch; -------------------------------------------------------------------------------- -- Company: <Name> -- -- File: mtest.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- <Description here> -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: <Name> -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use ieee.numeric_std.all; entity mtest is port ( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end mtest; architecture arch of mtest is -- signal, component etc. declarations type memory IS ARRAY (0 TO 31) of std_logic_vector(31 DOWNTO 0); --type memory IS ARRAY (31 DOWNTO 0) of std_logic_vector; signal myram: memory; --attribute ram_init_file: STRING; --attribute ram_init_file OF myram: SIGNAL IS "ram_contents.mif"; begin -- generation of data_out process(clk,nreset) begin if (nreset='0') then data_out <= x"0000_0000"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- data_out <= x"0000_0000"; -- elsif(rd_en='1') then if(rd_en='1') then data_out <= myram(to_integer(unsigned(address))); end if; end if; end process; -- writing data to memory process(clk,nreset) begin if (nreset='0') then myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; -- elsif(wr_en='1') then if (wr_en='1') then myram(to_integer(unsigned(address))) <= data_in; end if; end if; end process; end arch; [[Category:Mikroelektronikk]] cbc5a9161a5b19eb1da66bb5c54ae713c3aa04c2 6 428 1928 2013-09-27T13:13:42Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 429 1929 2013-09-27T13:29:25Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 430 1930 2013-09-27T13:29:42Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 431 1931 2013-09-27T13:30:00Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 432 1932 2013-09-27T13:30:19Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 433 1933 2013-09-27T13:30:39Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 434 1934 2013-09-27T13:31:03Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 435 1935 2013-09-27T13:31:26Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 436 1936 2013-09-27T13:31:45Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 437 1937 2013-09-27T13:32:11Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 439 1939 2013-09-27T13:33:08Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 440 1940 2013-09-27T13:33:26Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 441 1941 2013-09-27T13:33:45Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 442 1942 2013-09-27T13:34:03Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 443 1943 2013-09-27T13:34:20Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 444 1944 2013-09-28T07:52:44Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 445 1957 2013-09-30T06:47:32Z Cto070 76 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 370 1965 1667 2013-09-30T14:47:30Z Gge002 52 wikitext text/x-wiki ==Projects== * [[Applied Planetary Radio Astronomy]] * [[Phys117_-_PET_project|PET detector]] ==Useful stuff== * [[Inductance_meter|Inductance meter]] 3688ee510860c1d7107a31dd176be3b31089c9b3 1973 1965 2013-10-03T09:35:57Z Gge002 52 wikitext text/x-wiki ==Projects== * [[Applied Planetary Radio Astronomy]] * [[Phys117_-_PET_project|PET detector]] * [[Bore hole probe]] ==Useful stuff== * [[Inductance_meter|Inductance meter]] a258e232c2ac91257a0d40cb7436b59f2dc3e756 0 446 1966 2013-09-30T16:50:37Z Gge002 52 Created page with "==Objective== A traditional multimeter accessible to the hobbyist can measure all essential electric properties, including capacitance. The only property that still remains di..." wikitext text/x-wiki ==Objective== A traditional multimeter accessible to the hobbyist can measure all essential electric properties, including capacitance. The only property that still remains difficult to measure without extra investments (which can become rather essential) is inductance. Solenoids/coils are a significant part of any analogue circuit and, as opposed to all other discrete components, are often homemade. There are formulae helping to calculate parameters like number of windings, cross-section of the core etc, but one critically needs to verify the inductance of the final product. This article describes how one can build a rather accurate L-meter at home for probably less than $10. Here you will find the schematic, PCB layout, micro-controller source code; basically all you need to DIY. ==Description== The L-meter presented here is based on a rather popular solution using the LM311 comparator (see e.g. [http://electronics-diy.com/lc_meter.php]). It is stripped from the capacitance measuring capability due to micro-controller (MCU) source code size limitation. This limitation is dictated by the compiler I have used: MikroC PRO for PIC, ver. 6.0.0. The free license of the compiler allows up to 2k of program words (2066 to be exact, and the present code is 2065 program words). Other solutions omitting the LM311 and using built-in the MCU comparators can also be found (see e.g. [https://sites.google.com/site/vk3bhr/home/index2-html]). The MCU used in this project is PIC 16F88. Obviously, the code given below is also for this MCU. ==Specs== The L-meter presented here has a lower limit of ~1 µH and an upper limit of ~1MH (Mega Henry). Some sources (e.g. [http://electronics-diy.com/lc_meter.php]) claim lower limits as low as 10 nH, but I personally do not see how this can be achieved with the current solution. For more details see section "Theory and Schematic". ==Theory and Schematic== ==Layouts== ==Bill of materials== ==Code== ffb556f7add5826c7f6f5e4ad4208e0511b148b2 1969 1966 2013-09-30T20:44:35Z Gge002 52 wikitext text/x-wiki ==Objective== A traditional multimeter accessible to the hobbyist can measure all essential electric properties, including capacitance. The only property that still remains difficult to measure without extra investments (which can become rather essential) is inductance. Solenoids/coils are a significant part of any analogue circuit and, as opposed to all other discrete components, are often homemade. There are formulae helping to calculate parameters like number of windings, cross-section of the core etc, but one critically needs to verify the inductance of the final product. This article describes how one can build a rather accurate L-meter at home for probably less than $10. Here you will find the schematic, PCB layout, micro-controller source code; basically all you need to DIY. ==Description== The L-meter presented here is based on a rather popular solution using the LM311 comparator (see e.g. [http://electronics-diy.com/lc_meter.php]). It is stripped from the capacitance measuring capability due to micro-controller (MCU) source code size limitation. This limitation is dictated by the compiler I have used: MikroC PRO for PIC, ver. 6.0.0. The free license of the compiler allows up to 2k of program words (2066 to be exact, and the present code is 2065 program words). Other solutions omitting the LM311 and using built-in the MCU comparators can also be found (see e.g. [https://sites.google.com/site/vk3bhr/home/index2-html]). The MCU used in this project is PIC 16F88. Obviously, the code given below is also for this MCU. ==Specs== The L-meter presented here has a lower limit of ~1 µH and an upper limit of ~1MH (Mega Henry). Some sources (e.g. [http://electronics-diy.com/lc_meter.php]) claim lower limits as low as 10 nH, but I personally do not see how this can be achieved with the current solution. For more details see section "Theory and Schematic". ==Theory and Schematic== [[File:ChestotomerShema.png|400px|thumb|right|L-meter schematic]] The working principle of the schematic is as follows: # A tank circuit consisting of the capacitor C3 and the unknown coil will vibrate at a resonance frequency: ==Layouts== ==Bill of materials== ==Code== c2ac7713637c003051eea9aeebba4a4585ecdb98 1970 1969 2013-10-02T14:32:22Z Gge002 52 wikitext text/x-wiki ==Objective== A traditional multimeter accessible to the hobbyist can measure all essential electric properties, including capacitance. The only property that still remains difficult to measure without extra investments (which can become rather essential) is inductance. Solenoids/coils are a significant part of any analogue circuit and, as opposed to all other discrete components, are often homemade. There are formulae helping to calculate parameters like number of windings, cross-section of the core etc, but one critically needs to verify the inductance of the final product. This article describes how one can build a rather accurate L-meter at home for probably less than $10. Here you will find the schematic, PCB layout, micro-controller source code; basically all you need to DIY. ==Description== The L-meter presented here is based on a rather popular solution using the LM311 comparator (see e.g. [http://electronics-diy.com/lc_meter.php]). It is stripped from the capacitance measuring capability due to micro-controller (MCU) source code size limitation. This limitation is dictated by the compiler I have used: MikroC PRO for PIC, ver. 6.0.0. The free license of the compiler allows up to 2k of program words (2066 to be exact, and the present code is 2065 program words). Other solutions omitting the LM311 and using built-in the MCU comparators can also be found (see e.g. [https://sites.google.com/site/vk3bhr/home/index2-html]). The MCU used in this project is PIC 16F88. Obviously, the code given below is also for this MCU. ==Specs== The L-meter presented here has a lower limit of ~1 µH and an upper limit of ~1 MH (Mega Henry). Some sources (e.g. [http://electronics-diy.com/lc_meter.php]) claim lower limits as low as 10 nH, but I personally do not see how this can be achieved with the current solution. For more details see section "Theory and Schematic". ==Theory and Schematic== [[File:ChestotomerShema.png|400px|thumb|right|L-meter schematic]] The working principle of the schematic is as follows: # A tank circuit consisting of the capacitor C3 and the unknown coil (L<sub>x</sub>) will oscillate at a resonance frequency: <math>f = \frac{1}{2\pi\sqrt{LC}}</math> The schematic here is designed to work as a frequency counter, counting the frequency of oscillation of the aforementioned tank cirquit L<sub>x</sub>C3. Then if we know the value of C3 we can make the MCU measure the frequency, calculate L<sub>x</sub> and display it on the LCD: <math>L = (\frac{1}{2\pi f \sqrt{C}})^2</math> # Without L<sub>x</sub> connected, LM311 works as a free running multivibrator with a frequency on pin 7 ~1 Hz. When some L<sub>x</sub> is connected, pin 7 on LM311 starts oscillating with the frequency of the tank cirquit. The bigger L<sub>x</sub> the lower the frequency. Thus the upper limit of measurement will be limited by the frequency of the free running multivibrator (~1 Hz) and is therefore ~1 MH. # The rectangular pulses generated by LM311 will then be picked by the MCU, the frequency and inductance calculated and the inductance displayed on the LCD. In theory if the main oscillator frequency is 4 MHz (Tosc 0.25 μs), one cycle will be 4 x Tosc = 1 μs. An external clock signal going directly into the counter (pin T0CKI), without prescaler, should be high for longer than 2 x Tosc + 20 = 520 ns and low for at least the same time. This gives a total period of 1040 ns. Thus, the maximum input frequeny is 1/1040 ns = 961.5 KHz. If the prescaler is applied, according to the specs of PIC 16F88 the external clock input must be high/low for more than 10 ns. Consequently, the maximum countable frequency on pin T0CKI is 50 MHz. This would give a minimum measurable inductance ~10 nH. Why are we getting only 1 µH then? All boils down to the quality of the pulses LM311 in this configuration can give. The rising edge of these pulses has a relatively poor time constant, which results in a relatively slow saturation. Therefore, if the frequency is high enough the pulse will start falling before the rising edge has reached saturation, thus creating a train of jigsaw shaped pulses with an amplitude decreasing with the increase of the frequency, rather than rectangular ones. And for frequencies higher than what L<sub>x</sub> < 33 µH the pulse becomes so bad that the MCU cannot correctly interpret it. How can one go from 33 µH down to 1 µH for the minimum inductance measurement then? In the prototype I built the critical L<sub>x</sub> is 33 µH. Below this inductance the counter begins to generate more or less random numbers. But if one doesn't know that these are random numbers one might take them for real. Here L1 enters the picture. Whenever an unknown inductor is measured, it will be connected in series with L1 (added to it). Thus one will always measure at least 33 µH and will never get into the region of instability due to bad pulse shape. One adds to the code in the MCU an offset of -33 µH so that if one shortcircuits the L<sub>x</sub> input one will measure 0 µH. Now when one measures a 1 µH coil, the display will show 1 µH. If one wants to measure smaller inductances one needs to redesign the multivibrator part. ==Layouts== ==Bill of materials== ==Code== 383c2e591bd9efdcbf0d59c0902d2cf9fe8aade6 1971 1970 2013-10-03T07:55:16Z Gge002 52 wikitext text/x-wiki ==Objective== A traditional multimeter accessible to the hobbyist can measure all essential electric properties, including capacitance. The only property that still remains difficult to measure without extra investments (which can become rather essential) is inductance. Solenoids/coils are a significant part of any analogue circuit and, as opposed to all other discrete components, are often homemade. There are formulae helping to calculate parameters like number of windings, cross-section of the core etc, but one critically needs to verify the inductance of the final product. This article describes how one can build a rather accurate L-meter at home for probably less than $10. Here you will find the schematic, PCB layout, micro-controller source code; basically all you need to DIY. ==Description== The L-meter presented here is based on a rather popular solution using the LM311 comparator (see e.g. [http://electronics-diy.com/lc_meter.php]). It is stripped from the capacitance measuring capability due to micro-controller unit (MCU) source code size limitation. This limitation is dictated by the compiler I have used: MikroC PRO for PIC, ver. 6.0.0, not the MCU itself. The free license of the compiler allows up to 2k of program words (2066 to be exact, and the present code is 2065 program words). Other solutions omitting the LM311 and using built-in the MCU comparators can also be found (see e.g. [https://sites.google.com/site/vk3bhr/home/index2-html]). The MCU used in this project is PIC 16F88. The code given below is also for this MCU. The internal oscillator block is used, working at 4 MHz (selected by the OSCCON register, bits 6-4). The prescaler is set to 1:1 on the watchdog timer (OPTION_REG register, bits 2-0). ==Specs== The L-meter presented here has a lower limit of ~1 µH and an upper limit of ~1 MH (Mega Henry). Some sources (e.g. [http://electronics-diy.com/lc_meter.php]) claim lower limits as low as 10 nH, but I personally do not see how this can be achieved with the current solution. For more details see section "Theory and Schematic". Power source: 6-24 VDC adapter. ==Theory and Schematic== [[File:ChestotomerShema.png|600px|thumb|right|L-meter schematic (Erratum: J1 should receive more than 6 VDC and less than 24 VDC, not 5 VDC as in the schematic)]] The working principle of the schematic is as follows: * A tank circuit consisting of the capacitor C3 and the unknown coil (L<sub>x</sub>) will oscillate at a resonance frequency: <math>f = \frac{1}{2\pi\sqrt{LC}}</math> The schematic here is designed to work as a frequency counter, counting the frequency of oscillation of the aforementioned tank cirquit L<sub>x</sub>C3. Then if we know the value of C3 we can make the MCU measure the frequency, calculate L<sub>x</sub> and display it on the LCD: <math>L = (\frac{1}{2\pi f \sqrt{C}})^2</math> * Without L<sub>x</sub> connected, LM311 works as a free running multivibrator with a frequency on pin 7 ~1 Hz. When some L<sub>x</sub> is connected, pin 7 on LM311 starts oscillating with the frequency of the tank cirquit. The bigger L<sub>x</sub> the lower the frequency. Thus the upper limit of measurement will be limited by the frequency of the free running multivibrator (~1 Hz) and is therefore ~1 MH. * The rectangular pulses generated by LM311 will then be picked by the MCU, the frequency and inductance calculated and the inductance displayed on the LCD. Since the primary measured quantity in this project is frequency, we need to count pulses per unit time. Therefore using some kind of a counter mode of the MCU should be in order. PIC 16F88 has such a mode, as a good deal of the other PIC MCUs. This mode is selected in the OPTION_REG register (TOCS bit). When counter mode is selected, Timer0 counts the external clock pulses on RA4/AN4/T0CKI/C2OUT pin (pin 3). The timer/counter can be set to increment either on the rising or on the falling edge of every pulse arriving at RA4/AN4/T0CKI/C2OUT. This is software selectable by the T0SE (Timer0 Source Edge) bit of OPTION_REG. The counting range of the counter can be extended by the use of the prescaler or in the software. The latter technically does not increase the range of the counter, but it allows reaching very high counts. In the code below the latter method is used, since we are interested in counting every single pulse. Using a prescaler would cause inability to measure lower frequencies. In theory, if the oscillator frequency is 4 MHz (Tosc 0.25 μs), one cycle will be 4 x Tosc = 1 μs. An external clock signal going directly into the counter (pin RA4/AN4/T0CKI/C2OUT), without prescaler, should be high for longer than 2 x Tosc + 20 = 520 ns and low for at least the same time. This gives a total period of 1040 ns. Thus, the maximum input frequeny is 1/1040 ns = 961.5 KHz. If the prescaler is applied, according to the specs of PIC 16F88 the external clock input must be high/low for more than 10 ns. Consequently, the maximum countable frequency on pin RA4/AN4/T0CKI/C2OUT is 50 MHz. This would give a minimum measurable inductance ~10 nH. Why are we getting only 1 µH then? All boils down to the quality of the pulses LM311 in this configuration can give. The rising edge of these pulses has a relatively poor time constant, which results in a relatively slow saturation. Therefore, if the frequency is high enough the pulse will start falling before the rising edge has reached saturation, thus creating a train of jigsaw shaped pulses with an amplitude decreasing with the increase of the frequency, rather than rectangular ones. And for frequencies higher than what L<sub>x</sub> < 33 µH the pulse becomes so bad that the MCU cannot correctly interpret it. How can one go from 33 µH down to 1 µH for the minimum inductance measurement then? In the prototype I built the critical L<sub>x</sub> is 33 µH. Below this inductance the counter begins to generate more or less random numbers. But if one doesn't know that these are random numbers one might take them for real. Here L1 enters the picture. Whenever an unknown inductor is measured, it will be connected in series with L1 (added to it). Thus one will always measure at least 33 µH and will never get into the region of instability due to bad pulse shape. One adds to the code in the MCU an offset of -33 µH so that if one shortcircuits the L<sub>x</sub> input one will measure 0 µH. Now when one measures a 1 µH coil, the display will show 1 µH. If one wants to measure smaller inductances one needs to redesign the multivibrator part so that correctly shaped pulses are formed at higher frequencies. ==Layouts== ==Bill of materials== ==Code== f9aabf6ecb397146328daa8fbc5cd60a6952dbc3 1972 1971 2013-10-03T08:15:14Z Gge002 52 wikitext text/x-wiki ==Objective== A traditional multimeter accessible to the hobbyist can measure all essential electric properties, including capacitance. The only property that still remains difficult to measure without extra investments (which can become rather significant) is inductance. Solenoids/coils are an essential part of any analogue circuit and, as opposed to all other discrete components, are often homemade. There are formulae helping to calculate parameters like number of windings, cross-section of the core and so on for a desired inductance to be obtained, but one critically needs to verify the inductance of the final product. This article describes how one can build a rather accurate L-meter at home for probably less than $10. Here you will find the schematic, PCB layout, micro-controller source code; basically all you need to DIY. ==Description== The L-meter presented here is based on a rather popular solution using the LM311 comparator (see e.g. [http://electronics-diy.com/lc_meter.php]). It is stripped from the capacitance measuring capability due to micro-controller unit (MCU) source code size limitation. This limitation is dictated by the compiler I have used: MikroC PRO for PIC, ver. 6.0.0, not the MCU itself. The free license of the compiler allows up to 2k of program words (2066 to be exact, and the present code is 2065 program words). Other solutions omitting the LM311 and using built-in the MCU comparators can also be found (see e.g. [https://sites.google.com/site/vk3bhr/home/index2-html]). The MCU used in this project is PIC 16F88. The code given below is also for this MCU. The internal oscillator block is used, working at 4 MHz (selected by the OSCCON register, bits 6-4). The prescaler is set to 1:1 on the watchdog timer (OPTION_REG register, bits 2-0). ==Specs== The L-meter presented here has a lower limit of ~1 µH and an upper limit of ~1 MH (Mega Henry). Some sources (e.g. [http://electronics-diy.com/lc_meter.php]) claim lower limits as low as 10 nH, but I personally do not see how this can be achieved with the current solution. For more details see section "Theory and Schematic". Power source: 6-24 VDC adapter. ==Theory and Schematic== [[File:ChestotomerShema.png|600px|thumb|right|L-meter schematic (Erratum: J1 should receive more than 6 VDC and less than 24 VDC, not 5 VDC as in the schematic)]] The working principle of the schematic is as follows: * A tank circuit consisting of the capacitor C3 and the unknown coil (L<sub>x</sub>) will oscillate at a resonance frequency: <math>f = \frac{1}{2\pi\sqrt{LC}}</math> The schematic here is designed to work as a frequency counter, counting the frequency of oscillation of the aforementioned tank cirquit L<sub>x</sub>C3. Then if the value of C3 is known the MCU can measure the frequency, calculate L<sub>x</sub> and display it on the LCD: <math>L = (\frac{1}{2\pi f \sqrt{C}})^2</math> * Without L<sub>x</sub> connected, LM311 works as a free running multivibrator with a frequency on pin 7 ~1 Hz. When some L<sub>x</sub> is connected, pin 7 on LM311 starts oscillating with the frequency of the tank cirquit. The bigger L<sub>x</sub> the lower the frequency. Thus the upper limit of measurement will be limited by the frequency of the free running multivibrator (~1 Hz) and is therefore of the order of 1 MH. * The rectangular pulses generated by LM311 will then be picked by the MCU, the frequency and inductance calculated and the inductance displayed on the LCD. Since the primary measured quantity in this project is frequency, we need to count pulses per unit time. Therefore using some kind of a counter mode of the MCU should be in order. PIC 16F88 has such a mode, as a good deal of the other PIC MCUs. This mode is selected in the OPTION_REG register (TOCS bit). When counter mode is selected, Timer0 counts the external clock pulses on RA4/AN4/T0CKI/C2OUT pin (pin 3). The timer/counter can be set to increment either on the rising or on the falling edge of every pulse arriving at RA4/AN4/T0CKI/C2OUT. This is firmware selectable by the T0SE (Timer0 Source Edge) bit of OPTION_REG. The counting range of the counter can be extended by the use of the prescaler or in the firmware. The latter technically does not increase the range of the counter as such, but it allows reaching very high counts. In the code below the latter method is used, since we are interested in counting every single pulse. Using a prescaler would cause inability to measure lower frequencies. In theory, if the oscillator frequency is 4 MHz (Tosc 0.25 μs), one cycle will be 4 x Tosc = 1 μs. An external clock signal going directly into the counter (pin RA4/AN4/T0CKI/C2OUT), without prescaler, should be high for longer than 2 x Tosc + 20 = 520 ns and low for at least the same time. This gives a total period of 1040 ns. Thus, the maximum input frequeny is 1/1040 ns = 961.5 KHz. If the prescaler is applied, according to the specs of PIC 16F88 the external clock input must be high/low for more than 10 ns. Consequently, the maximum countable frequency on pin RA4/AN4/T0CKI/C2OUT is 50 MHz. This would give a minimum measurable inductance ~10 nH. Why are we getting only 1 µH then? All boils down to the quality of the pulses LM311 in this configuration can give. The rising edge of these pulses has a relatively poor time constant, which results in a relatively slow saturation. Therefore, if the frequency is high enough the pulse will start falling before the rising edge has reached saturation, thus creating a train of jigsaw shaped pulses with an amplitude decreasing with the increase of the frequency, rather than rectangular ones. And for frequencies higher than what L<sub>x</sub> < 33 µH can give the pulse becomes so bad that the MCU cannot correctly interpret it. How can one go from 33 µH down to 1 µH for the minimum inductance measurement then? In the prototype I built the critical L<sub>x</sub> is 33 µH. Below this inductance the counter begins to generate more or less random numbers. But if one doesn't know that these are random numbers one might take them for real. Here L1 enters the picture. Whenever an unknown inductor is measured, it will be connected in series with L1 (added to it). Thus, at least 33 µH will always be measured and the system will never get into the region of instability due to bad pulse shape. Then an offset of -33 µH is added in the firmware so that if the L<sub>x</sub> input is short circuited 0 µH will be displayed. Now when a 1 µH coil is measured, the display will show 1 µH. If smaller inductances are to be measured the multivibrator part needs to be redesigned, so that correctly shaped pulses are formed at higher frequencies. ==Layouts== ==Bill of materials== ==Code== a1e9cdaab8325a32ec9f899b62d70c07136ee3f3 6 447 1967 2013-09-30T16:52:30Z Gge002 52 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1968 1967 2013-09-30T17:00:40Z Gge002 52 Gge002 uploaded a new version of &quot;[[File:ChestotomerShema.png]]&quot; wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 448 1974 2013-10-03T09:45:07Z Gge002 52 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 449 1975 2013-10-03T09:50:00Z Gge002 52 Created page with "==GM counter== [[File:GMtube.jpg|200px|thumb|right|ZP1200 circuitry]] The GM counter for this project is ZP1200." wikitext text/x-wiki ==GM counter== [[File:GMtube.jpg|200px|thumb|right|ZP1200 circuitry]] The GM counter for this project is ZP1200. c3ace28797127ab704934410ebb2eaaab8c0ec89 1977 1975 2013-10-04T11:35:06Z Gge002 52 wikitext text/x-wiki ==Project description== In this project, radioactivity measurements will be performed in several Boreholes around Bergen region. Boreholes are drilled to provide thermal energy coming from hot underground water that is used to heat buildings. The goal of this project is to perform radioactivity measurements as a function of depth in Boreholes. The radioactivity will be monitored by means of a Geiger-Muller (GM) counter (Figure 1 shows the details of the detector to be utilized in this work). This is a gas-filled, cylindrical radiation counter that has found many industrial applications such as level gauges in the oil and gas industry. This is primarily due to the GM counter's robustness, low cost, simple read-out electronics and insensitivity to pressure and temperature changes in the environment. GM counters are also relatively insensitive to mechanical vibrations. These properties of the counter make it a good alternative for the pertinent measurements, as these will be carried out at varying depths in the boreholes. The counter will need to be lowered down as deep as 300 m. In order to carry out measurements across very long cables, there will be a need for a special detector data acquisition (DAQ) system, which includes electronic micro-controller, amplifier, pulse inverter, and hardware control programming. The project will start by designing the aforementioned DAQ system. Following a successful design, the system will be fabricated/built and tested. Once this is ready one can start measuring activities in Boreholes around the Bergen area. Students who are interested in radiation detection and detector readout electronics are very welcome. ==Supervisors== Prof. Dr. Bjarne Stugu Dr. Ilker Meric Dr. Enver Alagoz ==GM counter== [[File:GM_tube2.jpg|200px|thumb|right|Figure 1. Cross-sectional view of the ZP1200 GM counter. All dimensions are given in mm.]] [[File:GMtube.jpg|200px|thumb|right|Figure 2. ZP1200 circuitry]] The GM counter for this project is ZP1200. This is a Na-Halogen filled GM with a 446 stainless steel cathode. Its effective length is 38.1 mm. Operates in the temperature range from -40°C to +75°C. It has a max starting voltage of 325 V, an operating voltage range from 450 V to 650 V, recommended operating voltage of 500 V and a max slope of the plateau 6%/100V. The dead time of the detector is minimum 90 µs. It weighs 8 g. 58fc896a6d592740a630721aed9074d7143b7afb 6 450 1976 2013-10-04T11:20:46Z Gge002 52 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 424 1979 1978 2013-10-22T12:50:15Z Cto070 76 wikitext text/x-wiki =Intro= This tutorial explains how to implement and test a custom AMBA APB (Advanced Peripheral Bus) module. The tutorial will create a SmartFusion2 MSS (Microcontroller Subsystem) with APB bus interface. The custom module will be connected to the APB bus to map from APB bus to a DCS bus. Connected to the DCS part there will be a test module, which you can write and read from. The MSS will also have a GPIO module connected to a LED and serial UART peripheral. =Before you start= Make sure you have installed Libero and have a valid license, as described in [[SmartFusion2]]. This tutorial assumes Libero v11.1 is used and that you are using the SmartFusion2 starter kit from Microsemi. =Create new project= Start Libero SoC v11.1. Press ''Project'' and ''New Project''. Name your project ''APB_custom_peripheral''. Use system tools ''SmartFusion2 Microcontroller Subsystem (MSS)''. <br>[[File:New_project.jpg|400 px]] =Modify MSS= Double click on the MSS component to modify it. A new window will open. Enable/Disable peripherals until your MSS looks like the image below. <br> Tip: click ''View > Maximize Work Area'' or ''CTRL+W'' to expand the working area while enabling and disabling the MSS peripherals.<br> [[File:Modified_MSS.jpg|600 px]] Click on the configuration button for the enabled peripherals, and configure them like the following images<br> [[File:MSS_CCC.jpg|600 px]]<br> MSS CCC<br>[[File:MSS_reset.jpg|200 px]]<br> Reset Controller<br>[[File:FIC0.jpg|400px]]<br> FIC 0<br>[[File:MMUART.jpg|400 px]]<br> MMUART 0 Your MSS should now look like this: <br>[[File:MSS_finished.jpg|600 px]] =SmartDesign= Close the MSS configuration window. On the SmartDesign canvas, right click on the MSS component and ''Update instance(s) with Latest Component''.<br> From ''Catalog'' add the following components: '''CoreAPB3''' from ''Bus Interfaces'', <br> [[File:CoreAPB3_config.jpg|400 px]] '''Chip Oscillators''' and '''Clock Conditioning Circuitry''' from ''Clock & Management'' <br> [[File:Chip_osc.jpg|500 px]][[File:CCC_core.jpg|400 px]]<br> Now import all the vhdl files which are included at the bottom of the page. Save the files with the names specified in the text. The files can be included by clicking ''File'', ''Import'', ''HDL Source Files''. These files can now be found under ''hdl'' in the ''Files'' tab and in ''Design Hierarchy''. In ''Design Hierarchy'' right click on ''DCS_test'', choose ''Create Core from HDL''. Answer ''No'' to question about adding bus interfaces to core. Right click on ''apb_to_dcs'' and choose ''Create Core from HDL''. Choose ''Yes'' on question about adding bus interfaces to core. Choose ''Add/Edit bus interfaces...''. In next window, click ''Add Bus Interface...'', choose ''APB, AMBA, AMBA2, slave''. Connect ''PSELx'' to ''psel''.<br> [[File:Module_bus_interface.jpg|500 px]] Add the modules you made to the SmartDesign. In design canvas, right click and choose ''Auto Connect'' followed by ''Auto Arrange Instances''. Right click on ''MSS_RESET_N_F2M'' and ''GPIO_FABRIC'' and select ''Promote to Top Level''. Right click on ''reset_from_siu'' and choose ''Tie Low''. Connect the unconnected wires. The result should look something like the image below<br> [[File:SmartDesign_finished.jpg|700 px]] Generate component by clicking ''SmartDesign'' and ''Generate Component''. =Pre-synthesized Simulation= To simulate the functionality of the abp_to_dcs module, normal APB bus functionality from the MSS should be used. To do this you can add a .bfm file (Bus Functional Model). Copy the following to the User.bfm in your project, located under ''Files'' and ''simulation''. #=========================================================== # Enter your BFM commands in this file. # # Syntax: # ------- # # memmap resource_name base_address; # # write width resource_name byte_offset data; # read width resource_name byte_offset; # readcheck width resource_name byte_offset data; # #=========================================================== #include "subsystem.bfm" procedure user_main; # perform subsystem initialization routine # call subsystem_init; # add your BFM commands below: memmap apb_to_dcs_0 0x50000000; write w apb_to_dcs_0 0x0 0x12345678; write w apb_to_dcs_0 0x4 0xBEEFFACE; write w apb_to_dcs_0 0x8 0xABCDEF12; write w apb_to_dcs_0 0xC 0x44556622; readcheck w apb_to_dcs_0 0x0 0x12345678; readcheck w apb_to_dcs_0 0x4 0xBEEFFACE; readcheck w apb_to_dcs_0 0x8 0xABCDEF12; readcheck w apb_to_dcs_0 0xC 0x44556622; write w apb_to_dcs_0 0x10 0x98765432; write w apb_to_dcs_0 0x14 0xABBABABE; write w apb_to_dcs_0 0x18 0x12345ABC; write w apb_to_dcs_0 0x1C 0xDEADBEEF; readcheck w apb_to_dcs_0 0x10 0x98765432; readcheck w apb_to_dcs_0 0x14 0xABBABABE; readcheck w apb_to_dcs_0 0x18 0x12345ABC; readcheck w apb_to_dcs_0 0x1C 0xDEADBEEF; return Next, go to ''Project'' and then ''Project Settings''. Choose ''DO File'' under ''Simulation Options''. You can use the run.do file supplied below. If you want to use automatic .do file and add signals yourself you can use standard settings, but be sure to change simulation time to 150 us. The system has got some initialization time, which takes around 120 us with this setup, before the bus signals start to change. quietly set ACTELLIBNAME SmartFusion2 quietly set PROJECT_DIR "C:/Microsemi/Projects/APB_custom_peripheral" source "${PROJECT_DIR}/simulation/CompileDssBfm.tcl";source "${PROJECT_DIR}/simulation/bfmtovec_compile.tcl"; if {[file exists presynth/_info]} { echo "INFO: Simulation library presynth already exists" } else { vlib presynth } vmap presynth presynth vmap SmartFusion2 "C:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" if {[file exists COREAPB3_LIB/_info]} { echo "INFO: Simulation library COREAPB3_LIB already exists" } else { vlib COREAPB3_LIB } vmap COREAPB3_LIB "COREAPB3_LIB" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral_MSS/APB_custom_peripheral_MSS.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/dcs_interface_pkg.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/apb_to_dcs.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/mtest.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/hdl/DCS_test.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/FCCC_0/APB_custom_peripheral_FCCC_0_FCCC.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/OSC_0/APB_custom_peripheral_OSC_0_OSC.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_muxptob3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3_iaddr_reg.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/coreapb3.vhd" vcom -93 -explicit -work COREAPB3_LIB "${PROJECT_DIR}/component/Actel/DirectCore/CoreAPB3/4.0.100/rtl/vhdl/core_obfuscated/components.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/APB_custom_peripheral.vhd" vcom -93 -explicit -work presynth "${PROJECT_DIR}/component/work/APB_custom_peripheral/testbench.vhd" vsim -L SmartFusion2 -L presynth -L COREAPB3_LIB -t 1fs presynth.testbench add wave \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PREADY \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSLVERR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MCCC_CLK_BASE_PLL_LOCK \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_F2M \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PADDR \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PENABLE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PSEL \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PRDATA \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/FIC_0_APB_M_PWRITE \ sim:/testbench/APB_custom_peripheral_0/APB_custom_peripheral_MSS_0/MSS_RESET_N_M2F add wave \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/penable \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/psel \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwrite \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/paddr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pwdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/prdata \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pslverr \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/clk \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_n \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/reset_from_siu \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/global_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/rcu_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/fec_reset \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/pready \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/apb_to_dcs_0/siu_bg add wave \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/we_dcs \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBadd \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_busBdata_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bi \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/dcs_br \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/siu_bg \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/wr_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/rd_en \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/address \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_in \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/data_out \ sim:/testbench/APB_custom_peripheral_0/DCS_test_0/mtest_map/myram run 150 us Double click on ''Simulate'' in Design Flow under ''Verify Pre-Synthesized Design'' which will start ModelSim.<br> [[File:Presynth_transcript.jpg|400 px]]<br>[[File:Presynth_wave.jpg|700 px]] =Constraints, Synthesize and Place&Route= Go to ''Project'', ''Project Settings'', ''Device I/O Settings'' and set ''Default I/O Technology'' to ''LVCMOS 3.3V''. Import the Physical Design Constraint file supplied below. Name it Fabric_top.pdc. # Microsemi I/O Physical Design Constraints file # Auto Generated User I/O Constraints file # Version: v11.1 11.1.0.14 # Family: SmartFusion2 , Die: M2S050T_ES , Package: 896 FBGA # Date generated: Fri Sep 20 10:03:27 2013 # # User Locked I/O Bank Settings # set_iobank Bank0 -vcci 1.80 -fixed yes set_iobank Bank1 -vcci 3.30 -fixed yes set_iobank Bank2 -vcci 3.30 -fixed yes set_iobank Bank3 -vcci 3.30 -fixed yes set_iobank Bank4 -vcci 3.30 -fixed yes set_iobank Bank8 -vcci 3.30 -fixed yes # # Unlocked I/O Bank Settings # The I/O Bank Settings can be locked by directly editing this file # or by making changes in the I/O Attribute Editor # # # User Locked I/O settings # set_io MMUART_0_RXD -pinname L23 -fixed yes set_io MMUART_0_TXD -pinname H27 -fixed yes set_io MSS_RESET_N_F2M \ -pinname F30 \ -fixed yes \ -RES_PULL Up \ -DIRECTION INPUT set_io GPIO_0_M2F \ -pinname G30 \ -fixed yes \ -DIRECTION OUTPUT The file is imported by clicking ''File'', ''Import'', ''I/O Constraints (PDC) Files''. Once this is included, scroll in ''Design Flow'' to ''Place and Route'' and right click. Select ''Configure Options'' and uncheck ''Timing Driven''. Now you can click on the "Play" button, Generate Programming Data. This process will take some time. If all succeeds, you should be able to program your FPGA. Program it by connecting power and FlashPro Programmer and click on ''Run Programming Action''. =Create Test Software= To write test application software, scroll to the bottom of the Design Flow and click ''Write Application Code''. This will open SoftConsole from Microsemi. You can replace the main.c with the following: #include "unistd.h" #include <stdio.h> #include "drivers/mss_uart/mss_uart.h" #include "drivers/mss_gpio/mss_gpio.h" //Initialize registers to read/write #define APB_TO_DCS_0 0x50000000U #define MEM1 (*(volatile int32_t *) 0x50000000) #define MEM2 (*(volatile int32_t *) 0x50000004) #define MEM3 (*(volatile int32_t *) 0x50000008) #define MEM4 (*(volatile int32_t *) 0x5000000C) #define MEM5 (*(volatile int32_t *) 0x50000010) #define MEM6 (*(volatile int32_t *) 0x50000014) #define MEM7 (*(volatile int32_t *) 0x50000018) #define MEM8 (*(volatile int32_t *) 0x5000001C) //Define a constant delay value #define DELAY_LOAD_VALUE 0x00080000 //about half a second int main() { /* * Initialize MSS GPIOs. */ MSS_GPIO_init(); /* * Configure MSS GPIO pin */ MSS_GPIO_config( MSS_GPIO_0 , MSS_GPIO_OUTPUT_MODE ); /* * Set initial state of GPIO pin */ MSS_GPIO_set_output(MSS_GPIO_0,0); //Using UART 0 mss_uart_instance_t * const gp_my_uart = &g_mss_uart0; /* * Using one delay to write and one delay to read */ volatile int32_t delay_count_1 = 0; volatile int32_t delay_count_2 = 0; delay_count_1 = DELAY_LOAD_VALUE/2; delay_count_2 = DELAY_LOAD_VALUE; /* * Variable to read value from memory to set led */ uint8_t led; /* * Incrementing value to be written to memory */ int32_t i = 0; /* * Variables to hold values read from memory */ int32_t m1,m2,m3,m4,m5,m6,m7,m8; /* * data to be sent on UART, holding chopped memory data */ uint8_t data[4]; /*-------------------------------------------------------------------------- * Initialize and configure UART. */ MSS_UART_init(gp_my_uart, MSS_UART_57600_BAUD, MSS_UART_DATA_8_BITS | MSS_UART_NO_PARITY | MSS_UART_ONE_STOP_BIT); MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r*******************Hello World*********************\n\r"); //Always while( 1 ) { -- delay_count_1; -- delay_count_2; /* * Updating memory values */ if (delay_count_1 <= 0) { delay_count_1 = DELAY_LOAD_VALUE; MEM1 = i; MEM2 = i+1; MEM3 = i+2; MEM4 = i+3; MEM5 = i+4; MEM6 = i+5; MEM7 = i+6; MEM8 = i+7; } /* * Reading memory values */ if (delay_count_2 <= 0) { delay_count_2 = DELAY_LOAD_VALUE; m1 = MEM1; if(m1 != i) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 1 is different from expected! *****\n\r"); } /* * Chopping data from memory, sending it to UART. * Reading hex/binary values from console */ data[3] = m1; data[2] = m1 >>8; data[1] = m1 >>16; data[0] = m1 >>24; MSS_UART_polled_tx(gp_my_uart, data, sizeof(data)); m2 = MEM2; if(m2 != i+1) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 2 is different from expected! *****\n\r"); } m3 = MEM3; if(m3 != i+2) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 3 is different from expected! *****\n\r"); } m4 = MEM4; if(m4 != i+3) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 4 is different from expected! *****\n\r"); } m5 = MEM5; if(m5 != i+4) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 5 is different from expected! *****\n\r"); } m6 = MEM6; if(m6 != i+5) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 6 is different from expected! *****\n\r"); } m7 = MEM7; if(m7 != i+6) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 7 is different from expected! *****\n\r"); } m8 = MEM8; if(m8 != i+7) { MSS_UART_polled_tx_string(gp_my_uart,(const uint8_t*) "\n\r**** Data read on memory location 8 is different from expected! *****\n\r"); } /* * Read last bit of current value of m1 and set GPIO (led) according to the bit value * Bit should toggle for every read cycle */ led = m1 & 0x00000001; MSS_GPIO_set_output(MSS_GPIO_0,led); ++i; } } } The application will write data to RAM and then read it. A LED is linked to the LSB of the read data, which cause the LED to blink. Data read on first memory location is written to the UART, and can be observed with a serial terminal program. Note that serial data sent on the UART is counting binary, and ASCII format is not implemented. The UART also sends out a message on the UART if the read data is different from expected. Build Debug Application by pressing ''Debug Configurations'' and then choose ''Microsemi Cortex M3 Target''. Press ''Apply'', build debug target and launch debug target. <br> [[File:Debug_configuration.jpg|600 px]]<br>[[File:Debugging.jpg|600px]]<br>[[File:Debug_binary_count.jpg|600px]]<br> =VHDL files= ------------------------------------------------------------------------------- -- Title : APB_to_DCS -- Project : RCU2 ------------------------------------------------------------------------------- -- File : apb_to_dcs.vhd -- Last edited by : Christian Torgersen -- Last update : 30.09.2013 - 09:26 -- Current Revision : 1.0 ------------------------------------------------------------------------------- -- Description : Mapping between AMBA APB and DCS bus. ------------------------------------------------------------------------------- -- Revision History : ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway -- This file has been written by Christian Torgersen -- Christian.torgersen@student.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; library work; use work.dcs_interface_pkg.all; entity apb_to_dcs is port( --APB input control signals penable : in std_logic; -- APB enable signal. Asserted high on second pulse psel : in std_logic; -- APB slave select from master pwrite : in std_logic; -- APB direction setting --APB input and addr paddr : in std_logic_vector(31 downto 0); -- APB address pwdata : in std_logic_vector(31 downto 0); -- APB write data --APB output signals prdata : out std_logic_vector(31 downto 0); -- APB read data pready : out std_logic; -- APB hold signal, for read/write more than 2 cycles pslverr : out std_logic; -- APB slave error signal clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity reset_from_siu : in std_logic; -- asynch reset from SIU, positive polarity --internal resets global_reset : out std_logic; -- global reset, positive polarity rcu_reset : out std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : out std_logic; -- reset for FEC, positive polarity --DCS bus signals we_dcs : out std_logic; -- write enable to the internal modules dcs_busBadd : out std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : out std_logic; -- interrupt in case DCS needs bus dcs_bg : in std_logic; -- dcs bus grant from arbiter dcs_br : out std_logic; -- dcs bus request to arbiter siu_bg : in std_logic -- siu bus grant from arbiter ); end apb_to_dcs; architecture arc of apb_to_dcs is --signal declarations type state is (s_idle, s_wait_for_grant, s_grant, s_error); signal current_state, next_state : state; -- signal resetting : std_logic; -- high when the resetting addresses are received, only used by dcs_addr signal timeout :std_logic; signal timeout_cnt :std_logic_vector(6 downto 0); signal timeout_cnt_en :std_logic; signal we_dcs_i :std_logic; begin --combinatorics timeout <= timeout_cnt(6); we_dcs <= we_dcs_i; dcs_br <= '1' when (psel = '1'and (next_state = s_wait_for_grant or next_state = s_grant)) else '0'; dcs_busBadd <= paddr(15 downto 0); --linking between APB and dcs addresses dcs_busBdata_out <= pwdata when (pwrite='1' and dcs_bg= '1') else (others => '0'); -- APB to DCS data prdata <= dcs_busBdata_in when (pwrite ='0' and dcs_bg= '1') else (others => '0'); -- DCS to APB data -- purpose: timeout counter for transaction p_timeout_cnt: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt <= (others => '0'); elsif rising_edge(clk) then if (timeout_cnt_en = '1') then timeout_cnt <= timeout_cnt + 1; else timeout_cnt <= (others => '0'); end if; end if; end process p_timeout_cnt; -- purpose: state machine driver p_state_driver: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then current_state <= s_idle; elsif rising_edge(clk) then current_state <= next_state; end if; end process p_state_driver; --purpose: set next state p_next_state: process(current_state, dcs_bg, timeout, psel, penable) begin case current_state is when s_idle => if (dcs_bg = '1' and psel = '1' and penable = '0') then -- giving two cycle read/write possibility next_state <= s_grant; elsif (dcs_bg = '0' and psel = '1' and penable = '0') then --Three or more cycle read/write next_state <= s_wait_for_grant; else next_state <= s_idle; end if; when s_wait_for_grant => if (dcs_bg = '1') then next_state <= s_grant; elsif (timeout = '1') then next_state <= s_error; else next_state <= s_wait_for_grant; end if; when s_grant => next_state <= s_idle; when s_error => next_state <= s_idle; when others => next_state <= s_idle; end case; end process p_next_state; -- purpose: set outputs of module and internal signals p_output: process(clk, reset_n, reset_from_siu) begin if (reset_n = '0' or reset_from_siu = '1') then timeout_cnt_en <= '0'; we_dcs_i <= '0'; pslverr <= '0'; pready <= '1'; elsif rising_edge(clk) then --defaults case current_state is when s_idle => pslverr <= '0'; timeout_cnt_en <= '0'; when s_wait_for_grant => when s_grant => we_dcs_i <= '0'; pready <= '1'; when s_error => pslverr <= '1'; pready <= '1'; timeout_cnt_en <= '0'; when others => --defaults end case; case next_state is when s_idle => pready <= '1'; when s_wait_for_grant => timeout_cnt_en <= '1'; pready <= '0'; when s_grant => timeout_cnt_en <= '0'; pready <= '1'; we_dcs_i <= pwrite; when others => end case; end if ; end process p_output; --purpose: resets p_reset : process(clk, reset_n) begin if (reset_n = '0') then global_reset <= '1'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '1'; fec_reset <= '1'; elsif rising_edge(clk) then global_reset <= '0'; -- send reset when the circuit is being globally reseted by the reset line rcu_reset <= '0'; fec_reset <= '0'; if (we_dcs_i = '1') then case (paddr(15 downto 0)) is when c_global_reset => global_reset <= '1'; when c_rcu_reset => rcu_reset <= '1'; when c_fec_reset => fec_reset <= '1'; when others => -- do nothing end case; end if; end if; end process p_reset; --Purpose: Set up bus interrupt p_bus_int: process (clk, reset_n, reset_from_siu) begin if( reset_n = '0' or reset_from_siu = '1') then dcs_bi <= '0'; elsif (rising_edge(clk)) then if(siu_bg = '0' or dcs_bg = '1') then --do not interrupt if we have grant dcs_bi <= '0'; elsif (paddr (15 downto 0) = c_arbiter_irq) then dcs_bi <= '1'; end if; end if; end process p_bus_int; end architecture arc; ------------------------------------------------------------------------------- -- Title : DCS interface Package -- Project : RCU DCS interface ------------------------------------------------------------------------------- -- File : $RCSfile: dcs_interface_pkg.vhd,v $ -- Last edited by : $Author: alme $ -- Last update : $Date: 2008/02/15 12:23:43 $ -- Current Revision : $Revision: 1.4 $ ------------------------------------------------------------------------------- -- Description : Constant and function library for RCU Trigger Receiver -- design ------------------------------------------------------------------------------- -- Revision History : -- http://portal1.ift.uib.no/cgi-bin/viewcvs.cgi/vhdlcvs/rcu_cpld/ ------------------------------------------------------------------------------- -- -- This file is property of and copyright by the Instrumentation and -- Electronics Section, Dep. of Physics and Technology -- University of Bergen, Norway, 2005 -- This file has been written by Johan Alme -- Johan.Alme@ift.uib.no -- -- Permission to use, copy, modify and distribute this firmware and its -- documentation strictly for non-commercial purposes is hereby granted -- without fee, provided that the above copyright notice appears in all -- copies and that both the copyright notice and this permission notice -- appear in the supporting documentation. The authors make no claims -- about the suitability of this software for any purpose. It is -- provided "as is" without express or implied warranty. -- ------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; package dcs_interface_pkg is -- address information (this should be moved to a global adress mapping definition file.) -- memory spaces. -- Safety module address. Always ack these. constant c_MSM_space : std_logic_vector(3 downto 0):=X"8"; -- Actel space should NEVER be acked constant c_Actel_space : std_logic_vector(3 downto 0):=X"B"; -- treat as normal except for the subadresses 0xA00 and 0xA01 that should not be acked. constant c_trigger_space : std_logic_vector(3 downto 0):=X"4"; -- sub adresses -- belongs to trigger space. The two addresses are defined on the DCS board and should not be acked. constant c_dcsSetBunchReset : std_logic_vector(11 downto 0):= X"A00"; constant c_dcsSetEventReset : std_logic_vector(11 downto 0):= X"A01"; constant c_global_reset : std_logic_vector(15 downto 0):= X"5300"; constant c_fec_reset : std_logic_vector(15 downto 0):= X"5301"; constant c_rcu_reset : std_logic_vector(15 downto 0):= X"5302"; constant c_arbiter_irq : std_logic_vector(15 downto 0):= X"5310"; -- interrupts SIU grant constant c_grant : std_logic_vector(15 downto 0):= X"5311"; -- grant information given --Constant defining mem mapped mode on which the interface should be active constant c_memMappedMode0 : std_logic_vector(1 downto 0) := "00"; constant c_memMappedMode1 : std_logic_vector(1 downto 0) := "11"; end package dcs_interface_pkg; -------------------------------------------------------------------------------- -- Company: University of Bergen -- -- File: DCS_test.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- Component used to test functionality of apb_to_dcs bridge -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: Christian Torgersen -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity DCS_test is port ( clk : in std_logic; -- global clock (40 MHz) reset_n : in std_logic; -- asynch reset, negative polarity global_reset : in std_logic; -- global reset, positive polarity rcu_reset : in std_logic; -- reset for RCU Xilinx fw, positive polarity fec_reset : in std_logic; -- reset for FEC, positive polarity we_dcs : in std_logic; -- write enable to the internal modules dcs_busBadd : in std_logic_vector(15 downto 0); -- address passed through dcs_busBdata_in : in std_logic_vector(31 downto 0); -- data from internal modules to DCS dcs_busBdata_out : out std_logic_vector(31 downto 0); -- data to internal modules from DCS dcs_bi : in std_logic; -- interrupt in case DCS needs bus dcs_bg : out std_logic; -- dcs bus grant from arbiter dcs_br : in std_logic; -- dcs bus request to arbiter siu_bg : out std_logic -- siu bus grant from arbiter ); end DCS_test; architecture arch of DCS_test is -- signal, component etc. declarations signal data_outs :std_logic_vector(31 DOWNTO 0); signal wr_enable, rd_enable : std_logic; component mtest port( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end component; begin mtest_map: mtest port map( clk => clk, nreset => reset_n, wr_en => wr_enable, rd_en => rd_enable, address => dcs_busBadd(7 downto 0), data_in => dcs_busBdata_in, data_out => dcs_busBdata_out ); --dcs_busBdata_out <= data_outs; siu_bg <= '0'; rd_enable <= not(we_dcs); wr_enable <= we_dcs; -- to be used if checking two cycle read/write: --dcs_bg <= '1'; -- Used to test arbitration and wait states: p_arbitration: process (clk, reset_n) begin if reset_n = '0' then dcs_bg <= '1'; data_outs <= (others => '0'); elsif rising_edge(clk) then if (dcs_br = '1') then dcs_bg <= '1'; else dcs_bg<= '0'; end if; end if; end process p_arbitration; end arch; -------------------------------------------------------------------------------- -- Company: <Name> -- -- File: mtest.vhd -- File history: -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- <Revision number>: <Date>: <Comments> -- -- Description: -- -- <Description here> -- -- Targeted device: <Family::SmartFusion2> <Die::M2S050T_ES> <Package::896 FBGA> -- Author: <Name> -- -------------------------------------------------------------------------------- library IEEE; use IEEE.std_logic_1164.all; use ieee.numeric_std.all; entity mtest is port ( clk : IN std_logic; nreset : IN std_logic; wr_en : IN std_logic; rd_en : IN std_logic; address : IN std_logic_vector(7 DOWNTO 0); data_in : IN std_logic_vector(31 DOWNTO 0); data_out : OUT std_logic_vector(31 DOWNTO 0) ); end mtest; architecture arch of mtest is -- signal, component etc. declarations type memory IS ARRAY (0 TO 31) of std_logic_vector(31 DOWNTO 0); --type memory IS ARRAY (31 DOWNTO 0) of std_logic_vector; signal myram: memory; --attribute ram_init_file: STRING; --attribute ram_init_file OF myram: SIGNAL IS "ram_contents.mif"; begin -- generation of data_out process(clk,nreset) begin if (nreset='0') then data_out <= x"0000_0000"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- data_out <= x"0000_0000"; -- elsif(rd_en='1') then if(rd_en='1') then data_out <= myram(to_integer(unsigned(address))); end if; end if; end process; -- writing data to memory process(clk,nreset) begin if (nreset='0') then myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; elsif (clk'EVENT AND clk='1') then -- if (nreset='0') then -- myram(to_integer(unsigned(address))) <= x"DEAD_BEEF"; -- elsif(wr_en='1') then if (wr_en='1') then myram(to_integer(unsigned(address))) <= data_in; end if; end if; end process; end arch; [[Category:Mikroelektronikk]] 28bb95c0ca714855b2affda72e446d401baa1840 0 416 1980 1889 2013-11-16T20:04:33Z Lbr088 56 Added solution for Libero locked session problem wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Other designfiles and documents can be found here: http://emcraft.com/products/153 Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= * Rightclick in the library pan of Questasim and choose new->Library. * Choose "A map to an existing library". * Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. * Include the library in the files where you need SF2 cores The same applies for other actel devices. =Libero errors, warnings and problems= * If you get "Warning: CMP008: module_name is not an Actel cell defined in the cell library." it means the mentioned module was not included in the synthesis and thus assumed to be an Actel standard module. Rightclick synthesis and select "Organize input files->Organize source files" select the mentioned module and press add. * Generate programming data fails without explanation: Constraint format has changed between Libero versions. Generate a new constraint file using the I/O editor based on the data in the old constraint file. * When a project is opened, if there is a message saying that the project is already open in another instance of Libero, go to the folder ''tooldata'' in the project directory and delete a file called ''libero.xyzv''. Where xyzv is some four digit number. 1c412e5efcc74a357468aebebade121e68baa5c3 0 451 1981 2013-11-27T16:20:50Z Lbr088 56 Initilized page wikitext text/x-wiki == Init == 045c5cc8c158e37f95e88d10586b9bcbed052968 1982 1981 2013-11-27T17:16:28Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]. The firmware is compiled for the SmartFusion2 Starter Kit Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. ... f6fef77c140043f692c039a2bcae7ab4bce98a25 1983 1982 2013-11-27T21:06:03Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]. The firmware is compiled for the SmartFusion2 Starter Kit. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. More to come... 370d053cfd721b8fb7e53e77e2687afeac19d016 1984 1983 2013-11-28T09:52:41Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Set Up the SF2 Target == == Boot Linux Image == The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image. === Setup U-Boot enviroment === For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update <references /> 690edd1a27ac1bf42e3bc8455fc18ecbdbdbb559 1985 1984 2013-11-28T10:12:04Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Set Up the SF2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image. === Setup U-Boot enviroment === For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. <references /> 050f95840b77c664b5a8654369bf41385e5b931c 1986 1985 2013-11-28T10:20:49Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Set Up the SF2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rcu2linux/blob/master/rcu2linux.uImage?raw=true Github]. === Setup U-Boot enviroment === For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. <references /> b3fc47123920683db1b9fbf8410e99e32169a037 1987 1986 2013-11-28T10:21:28Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Set Up the SF2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rcu2linux/blob/master/rcu2linux.uImage?raw=true Github]. === Setup U-Boot enviroment === For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == References == <references /> 8bc521df9831d401adad6399c52bad75b734b5ed 1988 1987 2013-11-28T10:22:28Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rcu2linux/blob/master/rcu2linux.uImage?raw=true Github]. === Setup U-Boot enviroment === For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == References == <references /> b85a5ea4d9c7860b746bd0c23fd4fa560eef9485 1989 1988 2013-11-28T10:23:08Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rcu2linux/blob/master/rcu2linux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == References == <references /> f9310c8532c7937e57e328fa8d42823528e74ef8 1990 1989 2013-11-28T10:23:34Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rcu2linux/blob/master/rcu2linux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == References == <references /> ea4698ff35043c6bd9f5cb22736a4ae0be0e8a57 1993 1990 2013-11-28T10:42:03Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices. Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rcu2linux/blob/master/rcu2linux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == References == <references /> ddb81f08dab538f4e26e12f589868709b496d7d1 1994 1993 2013-11-28T12:26:02Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rcu2linux/blob/master/rcu2linux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rcu2linux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rcu2linux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == References == <references /> 9c6df16f479d5d326f16f111a4a918a2e2251fd3 1995 1994 2013-11-29T00:10:49Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 123.234.345.29 setenv serverip 123.234.345.12 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 172.17.1.20:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''test.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == References == <references /> 1edfce0cb413efea00062ee6ad845928b8b4bfe8 2010 1995 2014-01-06T12:11:42Z Lbr088 56 Updated with known problems wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> 87611746b1c3a9aeb7f095ee7c5c15a1669bd2c8 2011 2010 2014-01-06T12:14:14Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here (11.1)]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> d6f446a9896dc4e4c140b6c8e3f8210239e8044f 2012 2011 2014-01-06T12:17:00Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here (11.1)] or [http://www.tidsreise.com/rcu/System_w_Linux_11_2.zip here (11.2)]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> 46153ee3a778ca1b31ec7bd8712f424cf7aaa8a4 2016 2012 2014-03-10T09:58:22Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here (11.1)] or [http://www.tidsreise.com/rcu/System_w_Linux_11_2.zip here (11.2)]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update You should see something like this <verbatim> M2S-SOM> run update Using M2S_MAC device TFTP from server 192.168.1.10; our IP address is 192.168.1.11 Filename 'rculinux/rculinux.uImage'. Load address: 0xa0007fc0 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################### done Bytes transferred = 1869376 (1c8640 hex) 16384 KiB S25FL128S_64K at 0:0 is now current device Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done </verbatim> == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> b91696e3ddd29ff120f217f8cb88862937e5fa17 2017 2016 2014-03-10T09:59:03Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here (11.1)] or [http://www.tidsreise.com/rcu/System_w_Linux_11_2.zip here (11.2)]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update You should see something like this M2S-SOM> run update Using M2S_MAC device TFTP from server 192.168.1.10; our IP address is 192.168.1.11 Filename 'rculinux/rculinux.uImage'. Load address: 0xa0007fc0 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################### done Bytes transferred = 1869376 (1c8640 hex) 16384 KiB S25FL128S_64K at 0:0 is now current device Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> 31c92eb8472a436c8bca909d527d82a6202a6ad0 2018 2017 2014-03-10T09:59:20Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here (11.1)] or [http://www.tidsreise.com/rcu/System_w_Linux_11_2.zip here (11.2)]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update You should see something like this M2S-SOM> run update Using M2S_MAC device TFTP from server 192.168.1.10; our IP address is 192.168.1.11 Filename 'rculinux/rculinux.uImage'. Load address: 0xa0007fc0 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################### done Bytes transferred = 1869376 (1c8640 hex) 16384 KiB S25FL128S_64K at 0:0 is now current device Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> d83f2cdbf551ad15f26fd00773c364a0f0172e43 2019 2018 2014-03-10T10:30:45Z Lbr088 56 wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here (11.1)] or [http://www.tidsreise.com/rcu/System_w_Linux_11_2.zip here (11.2)]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update You should see something like this M2S-SOM> run update Using M2S_MAC device TFTP from server 192.168.1.10; our IP address is 192.168.1.11 Filename 'rculinux/rculinux.uImage'. Load address: 0xa0007fc0 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################### done Bytes transferred = 1869376 (1c8640 hex) 16384 KiB S25FL128S_64K at 0:0 is now current device Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done === Kermit mode === It is also possible to update the Linux image on the board through kermit mode (file transfer over serial link). In Linux you need a kermit client, e.g. ckermit or gkermit. To setup the client, create a config file (~/.kermrc) that should look something like this: set line /dev/ttyUSB0 define sz !sz \%0 > /dev/ttyUSB0 < /dev/ttyUSB0 set speed 115200 set carrier-watch off set prefixing all set parity none set stop-bits 1 set modem none set file type bin set file name lit set flow-control none set prompt "Linux Kermit> " Connect to the board by typing in a shell '''kermit''' then after kermit has started, type '''connect'''. If you are in Linux now, you reboot the board to get to the u-boot prompt. Once at the u-boot prompt, type M2S-SOM> loadb U-boot is now waiting for an image ## Ready for binary (kermit) download to 0xA0007FC0 at 115200 bps... Go back to kermit (''ctrl-\'' and ''ctrl-c'') then send the image Linux Kermit> send /home/lars/work/TPCRCU2/trunk/Firmware/Linux_image/rculinux.uImage Once finished (this takes about 3.5 minutes) go back to the board either by closing kermit and using your favorite serial client or by doing Linux Kermit> connect Connecting to /dev/ttyUSB0, speed 115200 Escape character: Ctrl-\ (ASCII 28, FS): enabled Type the escape character followed by C to get back, or followed by ? to see other options. ---------------------------------------------------- ## Total Size = 0x001c8640 = 1869376 Bytes ## Start Addr = 0xA0007FC0 M2S-SOM> flashboot The new image should now be booted. == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> 4909fc708c5081b45151417348012f0e72243974 2023 2019 2014-07-24T13:11:45Z Lbr088 56 added some missing steps in kermit mode flashing wikitext text/x-wiki == Programming == A FlashPro project including a STAPL programming file with firmware and u-boot images can be found [http://tidsreise.com/rcu/rcu2_linux_fw.zip here]<ref>[http://tidsreise.com/rcu/rcu2_linux_fw.zip Firmware]</ref>. The firmware is compiled for the SmartFusion2 Starter Kit and the device MS2050T_ES. The Libero project will be made available on the [https://svnweb.cern.ch/cern/wsvn/TPCRCU2 Subversion] directory ASAP in case you have other devices (for now, find the project [http://tidsreise.com/rcu/System_w_Linux.tar.gz here (11.1)] or [http://www.tidsreise.com/rcu/System_w_Linux_11_2.zip here (11.2)]). Usage: # Open FlashPro software # Select ''Open Project'' and find the file ''rcu2_linux_fw.pro'' # Make sure the FlashPro programmer is inserted and that it has been selected by pressing ''View Programmers''. If necessary, hit ''Refresh/Rescan for Programmers'' # Now hit ''PROGRAM'', wait for it to finish and then power cycle the board. For more information on FlashPro, check the user guide<ref>[http://www.microsemi.com/document-portal/doc_download/130809-flashpro-for-software-v11-0-user FlashPro User Guide]</ref>. == Setup of the SmartFusion2 Target == === Boot Linux Image === The Linux image is fetched from a network and can be booted directly from the network as well as loaded into the external Flash memory on the board. This requires a TFTP server to host the Linux image, for help on setting up a server, check the [[TFTP]] page. If you would like to quickly test the boot process, a Linux image can be fetched from [https://github.com/larks/rculinux/blob/master/rculinux.uImage?raw=true Github]. For now, the U-Boot enviroment has to be set manually. * Log in to the board through serial, baud rate 115200, 1 stop bit, no parity * Reset board and hit a key to stop boot sequence * Define the IP addresses for the target board and the TFTP server, as well as the name for the boot image. setenv ipaddr 192.168.1.11 setenv serverip 192.168.1.10 setenv image rculinux.uImage saveenv To run the image over the network, reset the board and stop the autoboot sequence, then type run netboot To load the image into the Flash, type run update You should see something like this M2S-SOM> run update Using M2S_MAC device TFTP from server 192.168.1.10; our IP address is 192.168.1.11 Filename 'rculinux/rculinux.uImage'. Load address: 0xa0007fc0 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################### done Bytes transferred = 1869376 (1c8640 hex) 16384 KiB S25FL128S_64K at 0:0 is now current device Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done === Kermit mode === It is also possible to update the Linux image on the board through kermit mode (file transfer over serial link). In Linux you need a kermit client, e.g. ckermit or gkermit. To setup the client, create a config file (~/.kermrc) that should look something like this: set line /dev/ttyUSB0 define sz !sz \%0 > /dev/ttyUSB0 < /dev/ttyUSB0 set speed 115200 set carrier-watch off set prefixing all set parity none set stop-bits 1 set modem none set file type bin set file name lit set flow-control none set prompt "Linux Kermit> " Connect to the board by typing in a shell '''kermit''' then after kermit has started, type '''connect'''. If you are in Linux now, you reboot the board to get to the u-boot prompt. Once at the u-boot prompt, type M2S-SOM> loadb U-boot is now waiting for an image ## Ready for binary (kermit) download to 0xA0007FC0 at 115200 bps... Go back to kermit (''ctrl-\'' and ''ctrl-c'') then send the image Linux Kermit> send /home/lars/work/TPCRCU2/trunk/Firmware/Linux_image/rculinux.uImage Once finished (this takes about 3.5 minutes) go back to the board U-boot prompt to write the image into the flash: Linux Kermit> connect Connecting to /dev/ttyUSB0, speed 115200 Escape character: Ctrl-\ (ASCII 28, FS): enabled Type the escape character followed by C to get back, or followed by ? to see other options. ---------------------------------------------------- ## Total Size = 0x001c8640 = 1869376 Bytes ## Start Addr = 0xA0007FC0 M2S-SOM> run spiprobe; sf erase ${spiaddr} ${filesize}; sf write ${loadaddr} ${spiaddr} ${filesize}; setenv spisize 0x${filesize}; saveenv; Once finished, you can boot the newly flashed image: M2S-SOM> run flashboot == Development == [http://emcraft.com/products/255#software Download] the Linux BSP and software development environment as well as the GNU tool-chain from Emcraft[http://emcraft.com/products/255#software Emcraft SF2 Starter kit downloads]. # Extract ''linux-M2S-1.11.0.tar.bz2'' to a preferred directory # Extract GNU toolchain ''arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2'' to directory ./linux-cortexm-1.11.0/tools # Make sure that the information in ''ACTIVATE.sh'' is correct and that the file is executable. # Source ACTIVATE.sh: ''. ACTIVATE.sh'' You are now ready for doing development. To create a new project, you can clone the ''developer'' project: lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ make clone new=test New project created in /home/lars/work/linux-cortexm-1.11.0/projects/test lars@borg-2:~/work/linux-cortexm-1.11.0/projects/developer$ cd ../test/ Or you can clone [https://github.com/larks/rculinux this] project from Github and copy it to the ''projects'' folder in your development enviroment. === Network and development === The startup script of the SF2 should be updated such that you can mount a directory from the development host onto the target board. This way you can compile any software you are working on, and run it straight away from the mount on the board. Add something along the following lines to ''local/rc'' in your project directory: mount -o nolock,rsize=1024 192.168.1.10:/home/lars/work/linux-cortexm-1.11.0/projects /mnt The mount directory needs to be added to the ramfs table, so add to ''rculinux.initramfs'': dir /mnt 755 0 0 After this is done, the image has to be recompiled and loaded to the board. == Known Problems == * In Libero, the path for the u-boot flash image is hard-linked, so if you are trying to run any of the project in the first section of this page, Libero might tell you that it did not find the flash file. If this should occur, it is needed to redefine the path to the image. ** 11.1 -- Go to the MSS configurator tab and double-click the eNVM part, in the configuration window for the eNVM, change to the correct path. ** 11.2 -- In ''Design Flow'' tab: Configure Security and Programming Options --> Update eNVM Memory Content. == References == <references /> 6fbc04890d995fc2fb0cb0468e393663d6259b0f 0 452 1991 2013-11-28T10:30:45Z Lbr088 56 Created page with "== TFTP setup procedure == === Ubuntu or Other Debian Based Distributions === Simply install from Aptitude sudo apt-get install xinetd tftpd tftp Create rule file /etc/xinetd..." wikitext text/x-wiki == TFTP setup procedure == === Ubuntu or Other Debian Based Distributions === Simply install from Aptitude sudo apt-get install xinetd tftpd tftp Create rule file /etc/xinetd.d/tftp service tftp { protocol = udp port = 69 socket_type = dgram wait = yes user = nobody server = /usr/sbin/in.tftpd server_args = /tftpboot disable = no } Create some directories to hold your files mkdir -p /export/tftpboot chmod 777 /export/tftpboot chown nobody /export/tftpboot Restart xinetd and the server should now be ready sudo service xinetd start === Windows === You can use TFTP32 from [http://tftpd32.jounin.net/ here]. An in-depth guide for setting up everything properly can be found [http://www.tricksguide.com/how-to-setup-a-tftp-server-tftpd32-windows.html here]. 77f0f6e740741c98dd8d2768cc6f47f1efa3350e 1992 1991 2013-11-28T10:33:26Z Lbr088 56 wikitext text/x-wiki == Setup == === Ubuntu or Other Debian Based Distributions === Simply install from Aptitude sudo apt-get install xinetd tftpd tftp Create rule file /etc/xinetd.d/tftp service tftp { protocol = udp port = 69 socket_type = dgram wait = yes user = nobody server = /usr/sbin/in.tftpd server_args = /tftpboot disable = no } Create some directories to hold your files mkdir -p /export/tftpboot chmod 777 /export/tftpboot chown nobody /export/tftpboot Restart xinetd and the server should now be ready sudo service xinetd start === Windows === You can use TFTP32 from [http://tftpd32.jounin.net/ here]. An in-depth guide for setting up everything properly can be found [http://www.tricksguide.com/how-to-setup-a-tftp-server-tftpd32-windows.html here]. 2b23ea7c0cbdff00894778e0c3f88c7d3a46ace2 6 453 1996 2013-12-04T12:13:09Z Tni071 73 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 25 1997 1918 2013-12-04T12:16:55Z Tni071 73 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven * [[SmartFusion2]] Oppsett og design med SF2 * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus [[Category:Mikroelektronikk]] 4d46deabaa914432a064c456414e553379f2a58f 0 454 1998 2013-12-04T12:17:37Z Tni071 73 Created page with "= Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for t..." wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [http://www.technoprint-smt.nl/downloads/manuals/rfo-ha02-manual.pdf here], while a quick search on the web for ``reflow soldering'' should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering is divided into two zones - ``preheat'' and ``reflow''. Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do It! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 1: Example of reflow soldering of MPPCs with thermal shielding and monitoring [[Category:Mikroelektronikk]] 102a5d7b1fedc69eb2967ed11a24202aa68d140e 1999 1998 2013-12-04T12:21:20Z Tni071 73 wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [http://www.technoprint-smt.nl/downloads/manuals/rfo-ha02-manual.pdf here], while a quick search on the web for "reflow soldering" should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering with this oven is divided into two zones - "preheat" and "reflow". Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do It! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 1: Example of reflow soldering of SiPMs with thermal shielding and monitoring [[Category:Mikroelektronikk]] d2f9951ad257885196d0abe6828811b7d1b604ac 2004 1999 2013-12-05T08:39:30Z Tni071 73 added some figures wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [http://www.technoprint-smt.nl/downloads/manuals/rfo-ha02-manual.pdf here], while a quick search on the web for ``reflow soldering'' should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering is divided into two zones - ``preheat'' and ``reflow''. Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. [[File:Thermocouple.jpg|816px]] Figure 1: Thermocouple used for temperature measurements [[File:Recommended_solder_profile.jpg|816px]] Figure 2: Recommended solder profile for Hamamatsu MPPC (From Hamamatsu S10362-11 series datasheet) [[File:Meas_solder_profile.jpg|816px]] Figure 3: Measured solder profile during reflow soldering == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do it! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 4: Example of reflow soldering of MPPCs with thermal shielding and monitoring [[Category:Mikroelektronikk]] [[Category:Mikroelektronikk]] fa4decaf508d4e2996ee10ad00079dbd3a5bcda3 2005 2004 2013-12-05T08:40:42Z Tni071 73 wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [http://www.technoprint-smt.nl/downloads/manuals/rfo-ha02-manual.pdf here], while a quick search on the web for ``reflow soldering'' should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering is divided into two zones - ``preheat'' and ``reflow''. Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. [[File:Thermocouple.jpg|816px]] Figure 1: Thermocouple used for temperature measurements [[File:Recommended_solder_profile.png|816px]] Figure 2: Recommended solder profile for Hamamatsu MPPC (From Hamamatsu S10362-11 series datasheet) [[File:Meas_solder_profile.png|816px]] Figure 3: Measured solder profile during reflow soldering == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do it! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 4: Example of reflow soldering of MPPCs with thermal shielding and monitoring [[Category:Mikroelektronikk]] [[Category:Mikroelektronikk]] cf5e44678c568ea5c3c56841ec2e84c421b95182 2006 2005 2013-12-05T08:41:33Z Tni071 73 wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [http://www.technoprint-smt.nl/downloads/manuals/rfo-ha02-manual.pdf here], while a quick search on the web for ``reflow soldering'' should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering is divided into two zones - ``preheat'' and ``reflow''. Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. [[File:Thermocouple.jpg|816px]] Figure 1: Thermocouple used for temperature measurements [[File:Recommended_solder_profile.png|816px]] Figure 2: Recommended solder profile for Hamamatsu MPPC (From Hamamatsu S10362-11 series datasheet) [[File:Meas_solder_profile.png|816px]] Figure 3: Measured solder profile during reflow soldering == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do it! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 4: Example of reflow soldering of MPPCs with thermal shielding and monitoring [[Category:Mikroelektronikk]] [[Category:Mikroelektronikk]] bf354bb9f68eeb94b47b677edd90f5244c921eac 2008 2006 2013-12-05T08:45:20Z Tni071 73 added user manual pdf wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [File:Rfo-ha02-manual.pdf here], while a quick search on the web for "reflow soldering" should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering is divided into two zones - "preheat" and "reflow". Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. [[File:Thermocouple.jpg|816px]] Figure 1: Thermocouple used for temperature measurements [[File:Recommended_solder_profile.png|816px]] Figure 2: Recommended solder profile for Hamamatsu MPPC (From Hamamatsu S10362-11 series datasheet) [[File:Meas_solder_profile.png|816px]] Figure 3: Measured solder profile during reflow soldering == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do it! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 4: Example of reflow soldering of MPPCs with thermal shielding and monitoring [[Category:Mikroelektronikk]] [[Category:Mikroelektronikk]] [[Category:Mikroelektronikk]] ead208c55b1fa834a455de772506f0baf4efdafa 2009 2008 2013-12-05T08:49:29Z Tni071 73 wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [[Media:Rfo-ha02-manual.pdf]], while a quick search on the web for "reflow soldering" should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering is divided into two zones - "preheat" and "reflow". Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. [[File:Thermocouple.jpg|816px]] Figure 1: Thermocouple used for temperature measurements [[File:Recommended_solder_profile.png|816px]] Figure 2: Recommended solder profile for Hamamatsu MPPC (From Hamamatsu S10362-11 series datasheet) [[File:Meas_solder_profile.png|816px]] Figure 3: Measured solder profile during reflow soldering == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do it! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 4: Example of reflow soldering of MPPCs with thermal shielding and monitoring [[Category:Mikroelektronikk]] [[Category:Mikroelektronikk]] [[Category:Mikroelektronikk]] e80055290005e0aad0f3b47a1b3986a69fb323cb 6 455 2000 2013-12-05T08:16:11Z Tni071 73 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 456 2001 2013-12-05T08:19:39Z Tni071 73 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 457 2002 2013-12-05T08:35:10Z Tni071 73 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2003 2002 2013-12-05T08:36:33Z Tni071 73 Tni071 uploaded a new version of &quot;[[File:Meas solder profile.png]]&quot; wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 458 2007 2013-12-05T08:42:46Z Tni071 73 Technoprint HA-02 reflow oven, user manual wikitext text/x-wiki Technoprint HA-02 reflow oven, user manual 0a548ea5c71ddecaf0e0cf888539e797dad7c57c 0 278 2013 1620 2014-02-26T10:13:38Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] 6fead84e3af4f53ab38a28a590531af245579810 0 415 2014 1894 2014-03-06T10:47:47Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'ams_cds -64 -tech c35b4 -nologo' Save file as cadence_ic_20xx_uib.csh csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh source /prog/cadence/cadence_ic_20xx_uib.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh 305cfe4f129e04dcd0a1958ba9c42cc686b787fe 2015 2014 2014-03-06T16:43:21Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'ams_cds -tech c35b4 -nologo' Save file as cadence_ic_20xx_uib.csh csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh source /prog/cadence/cadence_ic_20xx_uib.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh 924872f78d7dd02df09f6864b92eb765236c78da 0 399 2020 1779 2014-04-08T17:56:44Z Sya081 50 wikitext text/x-wiki ==Overview== This page contains step by step informations to setup the Focal readout electronics for MAPS detectors. ==Hardware requirements== *Focal read-out box *Linux computer with Gb network capability for taking data *Windows PC for software/firmware debugging *One or more patch panel PCBs *One or more flex PCBs with mounted MIMOSA ASICs ==Software requirements and drivers== *Xilinx Lab tools v13.2, including XMD, iMPACT and ChipScope *Serial console software like PuTTY *TFTP server for Linux kernel downloading ==Configure the FPGA(s)== ===Using XMD=== XMD could run from SDK or a normal cmd command window, for the later we need to set up the path environment firstly with batch file "settings32.bat"("settings64.bat" for a 64 bit PC) from the Xilinx software installation directory like "D:\Xilinx\13.2\ISE_DS\settings32.bat", for Linux, there are corresponded shell files. Copy the file to your work directory where firmware, boot-loader and Linux kernel are, replace the XIL_SCRIPT_LOC variable with an absolute path: <pre> set XIL_SCRIPT_LOC=D:\\Xilinx\\13.2\\ISE_DS\\ </pre> Open a cmd window, switch to your work directory, run: <pre> O:\phase1\xilinx\test> settings32.bat O:\phase1\xilinx\test> xmd </pre> After entering into XMD prompt window, using "fpga -f" command to program Virtex FPGA: <pre> XMD% fpga -f system.bit </pre> If there are more than one device in the JTAG chain, use "-debugdevice devicenr" to specify the component to be programmed, here we need to configure one Virtex6 and two Spartan6 FPGAs: <pre> XMD% fpga -f spartan6u1.bit -debugdevice devicenr 1 XMD% fpga -f spartan6u2.bit -debugdevice devicenr 2 XMD% fpga -f system.bit -debugdevice devicenr 4 </pre> ===Using iMPACT=== Run iMPACT from windows Start -> Xilinx ISE Design Suite 13.2 -> ISE Design Tools -> Tools -> iMPACT, or from the cmd window opened above, <pre> XMD% impact </pre> In the iMPACT window, select File -> Initialize Chain, then you will find the devices in the JTAG chain on the "Boundary Scan" window, right click on the FPGA you need to program, Assign a configuration file, then program it following the commands. ===Using Chipscope=== Sometimes we need chipscope to look inside FPGA by probing some of the internal signals, then it's convenient to program these FPGAs in Chipscope Analyzer. There is a chipscope project file together with a Chipscope definition and connection file - "chipscope.cpj" and "chipscope.cdc". Open the project file from Chipscope pro Analyzer version 13.2 or newer, after opening JTAG cable, all device in the JTAG chain will be shown in the left navigation window, right click on a device and select configure, then operate as indicated to program FPGA and run chipscope. ==Configure TFTP server== Open TFTP Server, select File -> Properties..., in "Preferences" page, enable "Allow Read Requests", in the "Directories" page, add the directory where the Linux kernel is placed. This configration is only needed at the first time. ==Microblaze debug module and Boot loader== In the XMD prompt window, you can connect to the Microblaze debug module to download and run your bootloader: <pre> XMD% connect mb mdm -debugdevice devicenr 4 XMD% dow u-boot.elf XMD% run </pre> If there is something wrong, like no response from the console, you can restart the system without reconfiguring Virtex6 FPGA: <pre> XMD% stop XMD% run </pre> Open a serial console like Putty, select the serial port which you can find from you windows Device Manager -> Ports(COM & LPT) -> Silicon Labs CP210x USB to UART Bridge(COM4), then com4 is the one we need to use, set Baud rate 115200, No Parity, 8 data bits, 1 stop bit. In the U-Boot command prompt window of Putty, modify the Virtex MAC/IP address and the TFTP server ip address at the first time, the MAC address could be found from the top side of Virtex6 DEV board, if there is a binding between the MAC and IP address, ask you network administrator for help, if the TFTP server and the readout box are in a private network, just pick a free IP address. <pre> U-Boot-PetaLinux> setenv ethaddr 00:0a:35:02:31:1f U-Boot-PetaLinux> setenv ipaddr 129.177.39.131 U-Boot-PetaLinux> setenv serverip 129.177.39.230 U-Boot-PetaLinux> saveenv </pre> Make sure the TFTP server is running and the kernel image is in the right directory, normally you should be able to ping each other. Then download the linux kernel from TFTP server: <pre> U-Boot-PetaLinux> tftp </pre> After the image being successfully downloaded, Boot Linux kernel: <pre> U-Boot-PetaLinux> bootm </pre> If you want to burn the kernel image to the on-board flash memory, run: <pre> U-Boot-PetaLinux> run update_kernel </pre> ==Running PetaLinux== After PetaLinux boots up, log in and set up network with your Virtex MAC/IP: <pre> ~ # ifconfig eth0 hw ether 00:0a:35:02:31:1f ~ # ifconfig eth0 129.177.39.131 </pre> If your network support dhcp: <pre> ~ # udhcpc </pre> To enable SSH service: <pre> ~ # dropbear </pre> To set up jumbo frame support for data shipment <pre> ~ # ifconfig eth0 down ~ # ifconfig eth0 mtu 9000 ~ # ifconfig eth0 txqueuelen 10000 ~ # /sbin/sysctl -w net.ipv4.tcp_sack=0 ~ # ifconfig eth0 up </pre> Before running the DAQ software, if the device driver has not been compiled into Linux kernle, then manually load it and make new device nodes in the /dev directory: <pre> ~ # /home/uib/load.sh </pre> All of the above configurations are now being put into an initiative script file, you can run it after logging in the system: <pre> ~ # /home/test/init.sh </pre> The above steps can also be done from a telnet terminal, after being initiated, the ssh server is running, you can connect the box from another pc with ssh connection. ===Startup scripts=== For the automatic running of the user initialization scripts, you can't add them directly to the romfs script files like /etc/rc.sysinit, because there files are generated every time during Petalinux compilation and all custom modification will be overwritten. The source files for these initialization scrips are located in "~petalinux-dist/user/sys_init/data/etc/rc", normally you should put your custom startup commands in "start" file, but according to the Makefile, this file doesn't work properly at the moment, so we add our scripts to the end of "sysinit" file: <pre> echo "Running user init scripts." /home/test/init.sh </pre> After running "make romfs", you will find that these scripts are added into the romfs file "/etc/rc.sysinit". ==Running DAQ== Start the server side DAQ software in the Linux DAQ server firstly, it will be waiting there for a connection: <pre> $ ./server </pre> Run the client side DAQ software: <pre> ~ # focal 0-3 </pre> The argument specifies the operation mode of the readout box: *0: Virtex test patterns as the input of DMA engine with FIFOs being bypassed, for every 256-bit word, there is a 32-bit counter and some other fixed long word patterns, as below: <pre> Data in [0x67000000..0x6700001f): 01 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 Data in [0x67000020..0x6700003f): 02 00 00 00 44 33 22 11 BB CC DD EE CC BB AA 99 00 FF EE DD 11 11 11 11 22 22 22 22 33 33 33 33 </pre> *1: Virtex test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter and two long word patterns) for each FIFO. Every 256-bit word is divided into two parts from the two FIFOs respectively, as below: <pre> Data in [0x67000000..0x6700001f): 41 91 01 00 44 33 22 11 BB CC DD EE 42 91 01 00 | 41 91 01 00 CC BB AA 99 00 FF EE DD 42 91 01 00 Data in [0x67000020..0x6700003f): 44 33 22 11 BB CC DD EE 43 91 01 00 44 33 22 11 | CC BB AA 99 00 FF EE DD 43 91 01 00 CC BB AA 99 Data in [0x67000040..0x6700005f): BB CC DD EE 44 91 01 00 44 33 22 11 BB CC DD EE | 00 FF EE DD 44 91 01 00 CC BB AA 99 00 FF EE DD </pre> *2: Spartan test patterns as the FIFO input, they are the test signals grouped by 96 bits(one 32-bit counter plus ASCII codes of "SPARTAN1" or "SPARTAN2") for each FIFO. They are very similar as in mode 1 except that these signals are from Spartan FPGAs, as below: <pre> Data in [0x67000000..0x6700001f): 42 91 01 00 31 4E 41 54 52 41 50 53 43 91 01 00 | 42 91 01 00 32 4E 41 54 52 41 50 53 43 91 01 00 Data in [0x67000020..0x6700003f): 31 4E 41 54 52 41 50 53 44 91 01 00 31 4E 41 54 | 32 4E 41 54 52 41 50 53 44 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 52 41 50 53 45 91 01 00 31 4E 41 54 52 41 50 53 | 52 41 50 53 45 91 01 00 32 4E 41 54 52 41 50 53 </pre> *3: The real data mode, at the input side of the two FIFOs, there are 96 bits from the 96 Mimosa data channels, at the output side of the FIFOs, the data is readout in 128 bits and the two FIFO outputs are connected together to form a 256-bit AXI4 word. With only the first 4 chips(16 channels) of the first Spartan FPGA being enabled and the other Spartan FPGA working in mode 2, the readout data format is as below: <pre> Data in [0x67000000..0x6700001f): 3F 3F 00 00 00 00 00 00 00 00 00 00 3F FF 00 00 | 41 91 01 00 32 4E 41 54 52 41 50 53 42 91 01 00 Data in [0x67000020..0x6700003f): 00 00 00 00 00 00 00 00 3F FF 00 00 00 00 00 00 | 32 4E 41 54 52 41 50 53 43 91 01 00 32 4E 41 54 Data in [0x67000040..0x6700005f): 00 00 00 00 7F 7F 00 00 00 00 00 00 00 00 00 00 | 52 41 50 53 44 91 01 00 32 4E 41 54 52 41 50 53 </pre> ==DAQ Configurations== ===Slow control setup=== The slow control setup is necessay for proper DAQ operations and it is done in the initialization part of the program before starting DAQ. All the parameters are read in from a configration file - "/home/test/parameters.txt". If this file can't be found/opened or errors occur during reading time, the default values which are hard coded will be selected. <pre> 0x00000F // U1_CHIP_ENABLE 1 bit for 1 chip [23 downto 0]. 24 bits, HEX 0x000 // U1_READOUT_CLK_SRC 2 bits for 1 layer[35 downto 24]. 12 bits, HEX 0x0 // U1_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal, [38 downto 36], 3 bits 0x1 // U1_PATTERN_LINE_EN enable pattern line for MAPS. 1 bit, [39] 0x0 // U1_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). [40] 0x1FF // U1_BKUP 9 bits for future use. [49 downto 41], HEX 0x000000 // U2_CHIP_ENABLE 2 bits for 1 chip [23 downto 0], HEX, LSB = chip 0 0x000 // U2_READOUT_CLK_SRC 1 bit for 1 layer, HEX 0x0 // U2_FRAME_SYNC_SRC use the MK_CLKD from the 1st layer as the source of frame_sync signal 0x1 // U2_PATTERN_LINE_EN enable pattern line for MAPS. 0x0 // U2_PATTERN_MODE pattern mode selection, 0: id/cnt, 1: toggle values(55/aa). 0x1FF // U2_BKUP 9 bits for future use, HEX </pre> Notes: *Chip_enable: 1=enable;0=disable. LSB = chip 1; *Readout_clk_src: 0b00=chip1(J10); 0b10=chip2(J11); 0b01=chip3(J13); 0b11=chip4(J12). LSB = Layer 1 *Frame_sync_src: 0=layer1...5=layer6. Make sure there is a working MK_CLKD signal for the selected layer. Slow control parameters will be saved inside Spartan FPGAs, so normally only one time of slow control operation is needed. ===Mimosa JTAG configuration=== Before DAQ starts to read out real detector data, all Mimosa asics need to be configured. This is done by a Linux program - "playxsvf", it reads in JTAG configurations from an xsvf format file and generates JTAG pin signals which are connected to a Spartan FPGA, these signals are then multiplexed to different patch pannel pcbs according to the address specified. To run this program: <pre> ~ # playxsvf XSVF Player v5.01, Xilinx, Inc. USAGE: playxsvf [-l layer] filename.xsvf where: -l layer = layer, no = 0-15 (default=0) filename.xsvf = the XSVF file to execute. ~ # playxsvf -l 1 /home/xsvf/pattern_4chips.xsvf </pre> Layer number: *1~6 for detector layer 1 to 6, 7 for all, these 6 layers are connected to Spartan U1 via the upper fanout board. *9~14 for detector layer 7 to 12, 15 for all, these 6 layers are connected to Spartan U2 via the lower fanout board. Four Mimosa chips in one detector layer share the same JTAG interface, they are configured one by one with others being bypassed, for different number of chips in the JTAG chain, there are different xsvf files, the position of the working chips in the JTAG also matters if not all chips are working. The enable/disable of the chips for JTAG configuration is determined by the slow control parameter "CHIP_ENABLE", if one chip is disabled, then it will also be bypassed from the JTAG chain. So it is important to finish the slow control before running JTAG configuration. Normally for the first time after the Spartan FPGAs are programmed or there are any modifications for the slow control parameters, we need to run "focal" program with a pattern mode firstly, then run JTAG configurtion before we can read out real detector data finally. All the JTAG configurations are saved inside Mimosa chips, so only one time of JTAG download is needed. ===Threshold voltage setup=== Normally the threshold voltages are set chip by chip with the values in the xsvf files. To change the values we need to regenerate the corresponded xsvf files with SVF to XSVF converter: "svf2xsvf502.exe". To automatically scan these voltages, it is possible to hack into the xsvf files and change the corresponded binary values and run it with xsvfplayer looply, but it is difficult when there are some chips not working inside a JTAG chain because there are different bit shifts inside the xsvf file for different chip position. This part is still under investigation. ==Running Chipscope== After programming FPGAs and configuring Mimosa chips, if something doesn't work properly, chipscope is the effective way to look into FPGAs to debug firmwares. For the current system, the Virtex and the two Spartan FPGAs share the same JTAG download cable, so they can work together in the same Chispcope project. After opening the Chipscope project file and initializing the JTAG cable, we can find the Spartan U1 and virtex chipscope interfaces, by setting up proper trigger conditions we could get the waveform of all the signals we want. *For Spartan U1, the chipscope signals include the frame_sync signal, the data ouput of the first chip(4 channels), the pattern verification results of these 4 channels and the total "not and" signal of all pattern match signals from the chips being enabled. If we trigger with "fram_sync_int", which is the signal for the start of the last line in a frame, we could see the pattern signal being programmed via JTAG, followed by the first several lines of data output from the first Mimosa chip, pattern_match value "1" means the pattern for current channel is matched. All match signals are "not anded" to an LED - "LED2_OBUF", if it is "0", all working chips have a matched pattern. <center>[[Image:chipscope_spartan.JPG]]</center> *For Virtex, there are signals related with the Focal unit and DMA engine, like the current counts of FIFOs, the FIFO status, external and internal(for test) frame_sync/spill_valid signals and so on. Normally it can be triggered with frame_sync, if you want to look know the status of FIFO, you can trigger with the FIFO_full/FIFO_empty or FIFO_count signals. ==Auto boot the system== After the firmware/bootloader/Linux developments are finished, we can burn these files into the on-board flash memories, to make the system boot up automatically after power on. There are three different kinds of flash memories available, a 2GB CF card, a 16MB platform flash and a 32MB BPI linear flash. We can put the FPGA configuration file in CF card or in the platform flash, and the BPI flash is the one for bootloader and Linux image. ===Program the CF card=== The CF card supports up to 8 configuration files, which is selected by the S1 switch on the Virtex board. We can generate a new .ace file with iMPACT and overwrite one of the 8 files in CF card, then enable the SysACE CF load and give the correct SysACE address: <pre> S1: 4 ON (SysACE Mode = 1) // Enable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, 0 means the first one(.ace file locates in /XILINX/cfg0/ directory in CF card) 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) 5 ON (M2 = 1) // JTAG mode 4 OFF (M1 = 0) 3 ON (M0 = 1) 2 ON (CS_SEL = 1) // Select Linear flash access 1 OFF (EXT_CCLK = 0) </pre> For the switch setups, please refer to [http://www.xilinx.com/support/documentation/boards_and_kits/ug534.pdf ML605 Hardware User Guide]. ===Program the Platform flash=== The platform flash supports in system programing, we can program it in iMPACT, with the .mcs file also generated in iMPACT. Please refer to [http://www.xilinx.com/support/documentation/user_guides/ug438.pdf Platform Flash XL Configuration and Storage Device]. Switches should be set up as below: <pre> S1: 4 OFF (SysACE Mode = 0) // Disable configuration load from CF card 3 OFF (SysACE Addr 2 = 0) // Three address bits, don't care here 2 OFF (SysACE Addr 1 = 0) 1 OFF (SysACE Addr 0 = 0) S2: 6 OFF (FLASH_A23 = 0) // Don't care in this mode 5 ON (M2 = 1) // Slave SelectMAP mode 4 ON (M1 = 1) 3 OFF (M0 = 0) 2 OFF (CS_SEL = 0) // Select Platform flash access 1 ON (EXT_CCLK = 1) </pre> ===Burn bootloader and Linux image=== This should be done in u-boot prompt window, for bootloader, we need binary file "u-boot-s.bin", which can be find in the petalinux-dist/images/ directory, you need to copy this file together with the linux kernel image "image.ub" to the TFTP server root directory. <pre> U-Boot-PetaLinux> run update_uboot U-Boot-PetaLinux> run update_kernel </pre> ==LED definitions== * D1: on: Test pattern out mode (mode 2) of Spartan1, off: normal mode; * D2: on: All enabled channels have correct patterns, off: at least one channel(1/4 of a chip) of pattern mismatch; * D3: flash: 1Hz from Spartan1 to Spartan2, maybe soldered up side down for some boxes; * D4: As D1, for Spartan2; * D5: As D2, for Spartan2; ==Useful links== # [http://www.xilinx.com/support/documentation/boards_and_kits/ug533.pdf Getting Started with the Xilinx Virtex-6 FPGA ML605 Evaluation Kit] # [http://www.xilinx.com/support/documentation/boards_and_kits/xtp055.pdf ML605 Restoring Flash Contents] # [http://www.xilinx.com/support/documentation/user_guides/ug360.pdf Virtex-6 FPGA Configuration User Guide] [[Category:Focal]] cfa85f86fea07bcf553277f6c6e4c7ec55763216 0 137 2021 1240 2014-04-15T14:11:20Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[From Higgs to Dark Matter 2014, in statu. nascendi]] === Job openings in our group=== we filled two postdoc positions in 2013, there will be a PhD position in 2014. * [[ ]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 88b59f21fc0439b023c0122f45e9ae37a8b4b084 0 234 2022 1783 2014-04-15T14:52:48Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Therese Sjursen -to be defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] e6980443aa0e149218561b1ac6b551b373448bd1 2024 2022 2014-07-29T15:02:15Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] a69a882187fadd6a7d8371a705a70127a77abd25 2025 2024 2014-08-20T11:51:09Z Nfyst 67 added some thesis titles (Bjarne) wikitext text/x-wiki == Theses, Notes, Publications, ... == === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] 532d975a955cd7adec58565159aea66d13730d69 0 202 2026 1696 2014-09-08T08:07:50Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [http://www.k-state.edu/ksuedl/publications/Technote%201%20-%20Equivalent%20Noise%20Bandwidth.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf Elementary Physics of P-N Junctions]] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * Symbolsk løsning av [[nodeligninger for en source-følger]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 583ca69bb54c457fd1823f9c3458c35778532f11 0 217 2027 734 2014-09-09T08:13:57Z Nfyku 4 wikitext text/x-wiki <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Kjetil Ullaland ligning1='(Vout-Vgs)/Zc+gm*Vgs+Vout/Rl=0'; ligning2='(Vgs-Vout)/Zc+(Vgs-Vin)/Rs=0'; ligning1=subs(ligning1,'1/(j*w*C)','Zc'); ligning2=subs(ligning2,'1/(j*w*C)','Zc'); pretty(ligning1); pretty(ligning2); disp('Solve for Vgs'); vgs_solved=solve(ligning2,'Vgs'); pretty(simplify(vgs_solved)); disp('Solve for Vout(vin)'); ligning3=subs(ligning1,vgs_solved,'Vgs'); Vout_solved=solve(ligning3,'Vout'); pretty(simplify(Vout_solved)) </pre> 7d8d9cc1f554e1f3a98dbeef7f1ac412d9272475 2028 2027 2014-09-09T08:17:03Z Nfyku 4 wikitext text/x-wiki <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Only Cgd is considered (Zc) % Kjetil Ullaland ligning1='(Vout-Vgs)/Zc+gm*Vgs+Vout/Rl=0'; ligning2='(Vgs-Vout)/Zc+(Vgs-Vin)/Rs=0'; ligning1=subs(ligning1,'1/(j*w*C)','Zc'); ligning2=subs(ligning2,'1/(j*w*C)','Zc'); pretty(ligning1); pretty(ligning2); disp('Solve for Vgs'); vgs_solved=solve(ligning2,'Vgs'); pretty(simplify(vgs_solved)); disp('Solve for Vout(vin)'); ligning3=subs(ligning1,vgs_solved,'Vgs'); Vout_solved=solve(ligning3,'Vout'); pretty(simplify(Vout_solved)) </pre> 24437330e3e8c21d349fa7da7ba03cfc95b61b9e 0 137 2029 2021 2014-09-11T15:11:52Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. For more info see [http://www.uib.no/fg/subatom/prosjekter/atlas Atlas Bergen UiB page]. For even more info see previous group page at [http://ift.iportal.uib.no/index.php?link_id=144809&sublink_id=145020&subsublink_id=&periode= Particle Group Page] . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send Thomas Burgess an e-mail and he will activate your account. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[From Higgs to Dark Matter 2014, in statu. nascendi, [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, there will be a PhD position in 2014, and PhD theory being announced now to start in 2015 all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] abc533836ea78b74ea2ba52e904d78208bae052a 0 3 2030 1800 2014-10-10T07:51:00Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Dominik.Fehlker Dominik Fehlker] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] c0ec053aed9d04ee496df2b72fbaad21de3ca0d5 2031 2030 2014-10-10T08:00:22Z Nfyku 4 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://svn.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 2793ffd3f930013d3735feefb2fd0508abec00d3 2050 2031 2014-10-31T17:28:54Z Ave082 33 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 7708f1fcc2dc1eda4aed176d882e92cbcf57394f 0 38 2032 1906 2014-10-10T17:29:15Z Ave082 33 Replaced content with "=Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm prosess ]] [[ AMS 3..." wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm prosess ]] [[ AMS 350nm prosess ]] [[Category:Mikroelektronikk]] b6012afb28dc27a6449716e0870b0a29b99e5bdc 2034 2032 2014-10-10T17:31:04Z Ave082 33 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ AMS 350nm process ]] [[Category:Mikroelektronikk]] aa646ecdb98a01992d6d1a77456cfbe9550f01b9 2048 2034 2014-10-22T12:20:01Z Oly002 83 wikitext text/x-wiki =Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ AMS 350nm process ]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[Category:Mikroelektronikk]] 9f92402ce0e9526d229ebbef612fcd7b9d2c02ad 0 460 2035 2014-10-10T17:31:18Z Ave082 33 Created page with "=Cadence design with AMS 350nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process..." wikitext text/x-wiki =Cadence design with AMS 350nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 6. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 7. To check and save the schematic, press 'X' or click the "Check and save" icon. Make sure you get no errors or warnings. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 8. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "vdc" node connected to the inverter input, the drain node of the nmos transistor and the net connected between the drain nodes of the nmos and pmos transistor. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol- [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. 7738da052ba5627e016390c83cae665a45c1ac3d 2037 2035 2014-10-10T20:48:52Z Ave082 33 wikitext text/x-wiki =Cadence design with AMS 350nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs, choose direction and click on the schematic to place it. Create one input and one output. 7. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 8. To check and save the schematic, press 'x' or click the "Check and save" icon. 9. If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 10. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 10. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol- [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. b1a65f6d5116d231e0a8c4f0a295071a5e864691 0 461 2036 2014-10-10T20:47:52Z Ave082 33 Created page with "=Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design proces..." wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh virtuoso & Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 7. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 8. To check and save the schematic, press 'x' or click the "Check and save" icon. 9. If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 10. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 11. Choose "Create > Test..." select the cell to simulate. 12. Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. 13. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 14. Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. ce27d5632407d321b42172b3cd8003bcd31aef2e 2038 2036 2014-10-15T20:25:29Z Ave082 33 wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh tsmc_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 7. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 8. To check and save the schematic, press 'x' or click the "Check and save" icon. 9. If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 10. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 11. Choose "Create > Test..." select the cell to simulate. 12. Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. 13. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 14. Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. fba004ce655128eeabc193235658cd2078be5249 2041 2038 2014-10-16T10:31:37Z Ave082 33 wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh tsmc_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 7. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 8. To check and save the schematic, press 'x' or click the "Check and save" icon. 9. If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 10. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 11. Choose "Create > Test..." select the cell to simulate. 12. Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. 13. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 14. Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. 2d6434f0cf6ef90acd09441abc05e9752f2ec356 0 415 2039 2015 2014-10-16T10:25:35Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="tcsh"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh 63e6da30d125874fbf23824c18f893ce625c2176 2040 2039 2014-10-16T10:28:39Z Ave082 33 wikitext text/x-wiki == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh dde35345583bea2ccd222b0f842bade336dc4f82 0 234 2042 2025 2014-10-16T16:18:32Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Submitted and yet not defended Phd Thesis=== *Alex Kastanas October 2014, defence scheduled for December, Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] ec7ff4daca76c2fbe27476d1bb38277d42a37183 2078 2042 2014-12-28T17:49:59Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications, ... == === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] c4512ac8e425e8a135f5172018d671083f6d1d0a 6 462 2043 2014-10-16T16:19:16Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 463 2044 2014-10-22T12:03:04Z Oly002 83 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 464 2045 2014-10-22T12:03:39Z Oly002 83 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 465 2046 2014-10-22T12:03:54Z Oly002 83 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 466 2047 2014-10-22T12:17:18Z Oly002 83 Created page with "This script can be used to print the operating point parameters of all transistors in your design. Navigate to the folder you want to save the script in (this tutorial uses..." wikitext text/x-wiki This script can be used to print the operating point parameters of all transistors in your design. Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This scipt uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a Debug Test with DC analysis: [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> The results file can also be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] [[Category:Mikroelektronikk]] 193e6ea6d4bfcdb18f175396d967eaf09f3add04 0 2 2049 1442 2014-10-31T17:11:51Z Ave082 33 wikitext text/x-wiki == Welcome == <center>[[Image:Bergen from Ulriken.gif]]</center> Welcome to the Wiki of the Experimental Nuclear Physics group at the Department of Physics and Technology at the University of Bergen (UiB). Its intended to represents a knowledge base for our current research and contributions to various projects. ---- Main aspect will be the [http://aliceinfo.cern.ch/index.html ALICE] experiment at [http://www.cern.ch CERN], but also [[other experiments]] will be found here. For ALICE, we are mainly involved in: * [[Detector Control System (DCS) for ALICE Front-end electronics]] * [[Electronics for the Time Projection Chamber (TPC)]] and Photon Spectrometer (PHOS) * [[SAMPA]] * [[FOCAL - Forward Calorimeter]] * [[PHOS PVSS panels]] * [[PHOS TOR]] * [[Busy Box and related]] * [[Xilinx Tools]] * [[HLT]] * [[GRID]] * [[Analysis]] * [[Coming to CERN]] <center>[[Image:alice.gif]]</center> 0f2b4768f3eec299aa9882d62beb9658f0556271 0 467 2051 2014-10-31T19:01:10Z Ave082 33 Created page with "== SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN] ==== Documentation ==== ====Registers====..." wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN] ==== Documentation ==== ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== Ther version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] b3e62069581e9bd54e75d9f662669ccc3b33b527 2052 2051 2014-10-31T19:11:53Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== Ther version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] c2b66e2d6314d808534bbf15e11708d3dba622ea 2053 2052 2014-10-31T19:12:06Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== Ther version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] 8d76935ec2d528135fcba984a71d09a0a0195089 2054 2053 2014-11-03T13:16:21Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] b779a92495166fb491557c8a5c4a8cda5568dd3f 2057 2054 2014-11-03T15:07:02Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] a34929c9a7ed15683135021fe91c939cb209bfa4 2058 2057 2014-11-03T15:07:20Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] dafd00b1093878ac89573827077ac3ea62add6ff 2061 2058 2014-11-06T18:04:20Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== Fixed mac: warm reboot, pree key to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 48daca0032a502df7965ab9c93237feda2bc6974 2062 2061 2014-11-17T15:07:57Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac for: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot c1b72ab245f0d7bf84ae9377306524d2cb60cb6a 2063 2062 2014-11-18T13:41:58Z Ave082 33 wikitext text/x-wiki == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 49f36c6dbc913ff9754ce50382bf91695832e061 2064 2063 2014-11-19T19:28:57Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot e38b61742600979e9b881e2d3965b71a45ab6f54 2065 2064 2014-11-19T21:38:23Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 7b6b324826520408829ee768c212d43b13e283d7 2066 2065 2014-11-19T21:39:10Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 1e3f37c50f05825313935a848fc2ce887974ed6b 2067 2066 2014-11-19T21:39:39Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 540b2292c69bf364edca5d5af47a87a7ebbd871b 2068 2067 2014-11-19T21:44:49Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] === Carrier board documentation === == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 0baefcda6e21218a19a6f198d03f7248fe97c536 2069 2068 2014-11-19T21:48:49Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] === Carrier boards === Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot dcb159c2cdac21be1e2e3baeab784827857c7347 2070 2069 2014-11-19T21:49:12Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 481b866f974807e9ca53f2acefe68afdcc7ea3d7 2072 2070 2014-11-19T21:59:52Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 26cc01a00eedb822f69c7fa7d68389e42758cfce 2073 2072 2014-11-20T20:15:59Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot 09b81d99aae8a3d1faa25c2d29b45d0a53e388f9 2074 2073 2014-12-10T14:16:49Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 017e655fa99dda1208906203adc9b806266a1c47 2075 2074 2014-12-18T10:48:32Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to [https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA]</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 2b2d2c21fc1266b7507ae611f32685c3a551905d 2076 2075 2014-12-18T10:49:07Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to [https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA CERN SAMPA wiki]</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 40484b898b459f74c382dce0b89b65c1a85a57d4 2077 2076 2014-12-18T10:50:35Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] cf3aaf507da491c55422093926ba29b6df9926bc 2079 2077 2015-01-10T13:44:48Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from ==== All latest files ==== ;::*[[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] ==== Revision 59 ==== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 95fa3d7cae8cca36c024095f75e4c1b57ebac8c3 0 468 2055 2014-11-03T14:15:36Z Ave082 33 Created page with "= SAMPA MPW1 Registers = == Channel specific registers == These are registers specific to each channel. By using a broadcast command, all channels can be written at the same..." wikitext text/x-wiki = SAMPA MPW1 Registers = == Channel specific registers == These are registers specific to each channel. By using a broadcast command, all channels can be written at the same time.<br /> {| class="wikitable" ! Register name ! ! Address ! Type ! Default value ! ! Description |- | K1 | [12:0] | 0x00 | RW | 0x00 | [12:0] | First pole of the TCFU |- | K2 | [12:0] | 0x01 | RW | 0x00 | [12:0] | Second pole of the TCFU |- | K3 | [12:0] | 0x02 | RW | 0x00 | [12:0] | Third pole of the TCFU |- | K4 | [12:0] | 0x03 | RW | 0x00 | [12:0] | Fourth pole of the TCFU |- | L1 | [12:0] | 0x04 | RW | 0x00 | [12:0] | First zero of the TCFU |- | L2 | [12:0] | 0x05 | RW | 0x00 | [12:0] | Second zero of the TCFU |- | L3 | [12:0] | 0x06 | RW | 0x00 | [12:0] | Third zero of the TCFU |- | L4 | [12:0] | 0x07 | RW | 0x00 | [12:0] | Fourth zero of the TCFU |- | ZSTHR | [19:0] | 0x08 | RW | 0x0A | [9:0] | Zero suppression threshold |- | | | | RW | 0x00 | [19:10] | Zero suppression offset |- | ZSCFG | [6:0] | 0x09 | RW | 0x02 | [1:0] | Glitch filter, minimum accepted pulse |- | | | | RW | 0x07 | [4:2] | Post-samples |- | | | | RW | 0x03 | [6:5] | Pre-samples |- | VFPED | [19:0] | 0x0A | RW | 0x00 | [9:0] | BC1 Fixed pedestal |- | | | | R | 0x00 | [19:10] | BC1 variable pedestal |- | CTE | [9:0] | 0x0B | RW | 0x00 | [9:0] | Channel specific noise |- | PMDTA | [9:0] | 0x0C | RW | 0x00 | [9:0] | Data to be stored in the pedestal memory |} == Global registers == These are global registers and does not accept broadcast commands.<br /> {| class="wikitable" ! Register name ! ! Address ! Type ! Default value ! ! Description |- | PMADD | [9:0] | 0x0D | RW | 0x00 | [9:0] | Pedestal memory address |- | BC2THR | [19:0] | 0x0E | RW | 0x03 | [8:0] | Lower threshold of moving average filter |- | | | | RW | 0x03 | [17:9] | Higher threshold of moving average filter |- | | | | RW | 0x01 | [19:18] | Number of taps in moving average filter |- | TRCFG | [19:0] | 0x0F | RW | 0x00 | [7:0] | Number of pre-samples (Pretrigger delay), max 191 |- | | | | RW | 0x3FD | [17:8] | Number of samples per event, max 1021 |- | DPCFG | [11:0] | 0x10 | RW | 0x00 | [3:0] | BC1 mode, see ALTRO manual |- | | | | RW | 0x00 | [4] | BC1 polarity |- | | | | RW | 0x07 | [6:5] | BC2 pre-samples |- | | | | RW | 0x07 | [10:7] | BC2 post-samples |- | | | | RW | 0x01 | [1] | BC2 moving average filter enable |- | VACFG | [7:0] | 0x11 | RW | 0x00 | [1:0] | Number of neighbors, not in use |- | | | | RW | 0x01 | [3:2] | Number of serial out, see table 1.5 |- | | | | RW | 0x00 | [4] | Pedestal mode enabled (zero suppression threshold 0) |- | | | | RW | 0x01 | [5] | Power save mode enabled |- | | | | RW | 0x00 | [6] | TCFU enabled |- | | | | RW | 0x01 | [7] | Continuous mode enabled |- | BC1THR | [13:0] | 0x12 | RW | 0x03 | [4:0] | Lower threshold of variable pedestal filter |- | | | | RW | 0x03 | [9:5] | Higher threshold of variable pedestal filter |- | | | | RW | 0x01 | [13:10] | Number of taps in variable pedestal filter |- | TRCNT | [15:0] | 0x13 | R | 0x00 | [15:0] | Trigger count |- | HWADD | [4:0] | 0x14 | R | 0x00 | [4:0] | Chip address (hardware address) |- | ERRORS | [5:0] | 0x15 | R | 0x00 | [0] | Parity error in received instruction |- | | | | R | 0x00 | [1] | Instruction error |- | | | | R | 0x00 | [2] | Trigger overlap |- | | | | R | 0x00 | [3] | SEU in MMU SM (not implemented) |- | | | | R | 0x00 | [4] | SEU in interface SM (not implemented) |- | BXCNT | [19:0] | 0x16 | R | 0x00 | [19:0] | Bunch crossing counter |} == Command registers == These are command registers and can only be written to. The value doesn’t matter as only the access is detected.<br /> {| class="wikitable" ! Register name ! Address ! Type ! Description |- | SWTRG | 0x1B | W | Software trigger (not implemented) |- | TRCLR | 0x1C | W | Clear trigger counter |- | ERCLR | 0x1D | W | Clear errors |- | BXCLR | 0x1E | W | Clear bunch crossing counter |- | SRST | 0x1F | W | Software reset |} 648791fd3b34b72e9b40774aad189d9161760120 0 469 2056 2014-11-03T14:45:49Z Ave082 33 Created page with "= SAMPA DAQ Registers = == Command and Control module registers == The registers for the command and control module, located at address 0x0000 from the UART or 0xFF200000 fro..." wikitext text/x-wiki = SAMPA DAQ Registers = == Command and Control module registers == The registers for the command and control module, located at address 0x0000 from the UART or 0xFF200000 from the HPS, is listed in table 4.1 {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | SC_ADD | [15:0] | 0x00 | RW | 0x00 | [4:0] | Slow control: Register address |- | | | | RW | 0x00 | [9:5] | Slow control: Channel address |- | | | | RW | 0x00 | [13:10] | Slow control: Chip address |- | | | | RW | 0x00 | [14] | Slow control: Broadcast |- | | | | RW | 0x00 | [15] | Slow control: Write/ not read |- | SC_DAT | [19:0] | 0x01 | RW | 0x00 | [19:0] | Slow control: Data to write |- | SC_MASK | [19:0] | 0x02 | RW | 0x00 | [19:0] | Slow control: Mask for writing * |- | CMD | [31:0] | 0x03 | RW | 0x00 | [15:0] | Commands, see table 4.2 |- | | | | RW | 0x00 | [31:15] | Loop count for commands |- | SC_RLT | [19:0] | 0x04 | R | 0x00 | [12:0] | Slow control: Response from SAMPA |- | SC_ERR | [1:0] | 0x05 | R | 0x00 | [0] | Error: Timeout waiting for response from slow control |- | | | | R | 0x00 | [1] | Error: Response from SAMPA not as expected |- | LNK_STS | [31:0] | 0x06 | R | 0x00 | [31:0] | Ethernet link status * |- | EVT_CFG | [31:0] | 0x07 | RW | 0x01 | [1:0] | Test signal output, see table 4.3 |- | | | | RW | 0x00 | [2] | Enable SLVS testing |- | | | | RW | 0x00 | [3] | Enable continuous readout of shiftregister |- | | | | RW | 0x00 | [31:3] | Reserved * |- | EVT_CNT | [31:0] | 0x08 | R | 0x00 | [31:0] | Reserved * |- | EV_BL | [31:0] | 0x09 | R | 0x00 | [31:0] | Reserved * |- | SMP_STS1 | [30:0] | 0x0A | R | | | Status of signals to and from SAMPA (updated every clock cycle) |- | | | | R | | [12:0] | Test data output from SAMPA |- | | | | R | | [16:13] | Serial out [3:0] |- | | | | R | | [18:17] | Number of serial out |- | | | | R | | [19] | Enable ZSU |- | | | | R | | [20] | Enable BC2 |- | | | | R | | [21] | Enable TCFU (deprecated) |- | | | | R | | [22] | Enable BC1 |- | | | | R | | [25:23] | Select test output |- | | | | R | | [26] | Select ADC0 or test input |- | | | | R | | [30:27] | Chip address |- | SMP_STS2 | [5:0] | 0x0B | R | | | Status of signals to and from SAMPA cont. |- | | | | R | | [0] | Slow control to SAMPA |- | | | | R | | [1] | Slow control from SAMPA |- | | | | R | | [2] | Reset_n |- | | | | R | | [3] | Event trigger |- | | | | R | | [4] | Heartbeat trigger |- | | | | R | | [5] | Sync signal |- | SMP_CFG | [13:0] | 0x0C | RW | | | SAMPA static signals, see SAMPA spec document for further details |- | | | | RW | 0x02 | [1:0] | Number of serial out |- | | | | RW | 0x00 | [2] | Enable ZSU |- | | | | RW | 0x00 | [3] | Enable BC2 |- | | | | RW | 0x01 | [4] | Enable TCFU |- | | | | RW | 0x01 | [5] | Enable BC1 |- | | | | RW | 0x03 | [8:6] | Select test output |- | | | | RW | 0x01 | [9] | Select ADC0 or test input |- | | | | RW | 0x01 | [13:10] | Chip address |- | SLVS_ERR | [15:0] | 0x0D | R | 0x00 | | SLVS errors detected |- | RAD_ERR | [31:0] | 0x0E | R | | | Errors detected in shiftregister test |- | | | | R | 0x00 | [15:0] | Bit 0 errors |- | | | | R | 0x00 | [31:16] | Bit 1 errors |} Commands for command and control unit. {| class="wikitable" ! Value ! Description |- | 0x1 | Reset FPGA and SAMPA |- | 0x2 | Reset SAMPA |- | 0x3 | Send event trigger |- | 0x4 | Send heartbeat trigger |- | 0x5 | Send sync signal |- | 0x6 | Run readout of shiftregister once (RAD) |- | 0x7 | Reset errors in shiftregister count (RAD_ERR) |- | 0x8 | Execute slow control command |- | 0x9 | Reset HPS |} Test signals available for generation. {| class="wikitable" ! Value ! Description |- | 0x0 | Constant zeros |- | 0x1 | Sine wave, full wave, 512 samples pulse width |- | 0x2 | Saw wave, full wave, 512 samples pulse width |- | 0x3 | Triangle wave, full wave, 1024 samples pulse width |} == Data manager registers == The registers for the data manager module, located at address 0x0040 from the UART or 0xFF201000 from the HPS, is listed in table 4.4. {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | CNTRL | [7:0] | 0x00 | RW | 0x00 | | Control register |- | | | | RW | 0x00 | [0] | Enable acquisition |- | | | | RW | 0x00 | [7:1] | Reserved |- | PKT0 | [31:0] | 0x01 | R | 0x00 | [31:0] | Packets written to memory from channel 0 |- | PKT1 | [31:0] | 0x02 | R | 0x00 | [31:0] | Packets written to memory from channel 1 |- | PKT2 | [31:0] | 0x03 | R | 0x00 | [31:0] | Packets written to memory from channel 2 |- | PKT3 | [31:0] | 0x04 | R | 0x00 | [31:0] | Packets written to memory from test-input/ADC |- | FIFO0 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 0 |- | FIFO1 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 1 |- | FIFO2 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 2 |- | FIFO3 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 3 |} 6c387788f1f80bfa4b1bc7a695e696eb43a9636c 2059 2056 2014-11-03T15:19:06Z Ave082 33 wikitext text/x-wiki = SAMPA DAQ Registers = == Command and Control module registers == The registers for the command and control module, located at address 0x0000 from the UART or 0xFF200000 from the HPS, is listed in table 4.1 {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | SC_ADD | [15:0] | 0x00 | RW | 0x00 | [4:0] | Slow control: Register address |- | | | | RW | 0x00 | [9:5] | Slow control: Channel address |- | | | | RW | 0x00 | [13:10] | Slow control: Chip address |- | | | | RW | 0x00 | [14] | Slow control: Broadcast |- | | | | RW | 0x00 | [15] | Slow control: Write/ not read |- | SC_DAT | [19:0] | 0x01 | RW | 0x00 | [19:0] | Slow control: Data to write |- | SC_MASK | [19:0] | 0x02 | RW | 0x00 | [19:0] | Slow control: Mask for writing * |- | CMD | [31:0] | 0x03 | RW | 0x00 | [15:0] | Commands, see table 4.2 |- | | | | RW | 0x00 | [31:15] | Loop count for commands |- | SC_RLT | [19:0] | 0x04 | R | 0x00 | [12:0] | Slow control: Response from SAMPA |- | SC_ERR | [1:0] | 0x05 | R | 0x00 | [0] | Error: Timeout waiting for response from slow control |- | | | | R | 0x00 | [1] | Error: Response from SAMPA not as expected |- | LNK_STS | [31:0] | 0x06 | R | 0x00 | [31:0] | Ethernet link status * |- | EVT_CFG | [31:0] | 0x07 | RW | 0x01 | [1:0] | Test signal output, see table 4.3 |- | | | | RW | 0x00 | [2] | Enable SLVS testing |- | | | | RW | 0x00 | [3] | Enable continuous readout of shiftregister |- | | | | RW | 0x00 | [31:3] | Reserved * |- | EVT_CNT | [31:0] | 0x08 | R | 0x00 | [31:0] | Reserved * |- | EV_BL | [31:0] | 0x09 | R | 0x00 | [31:0] | Reserved * |- | SMP_STS1 | [30:0] | 0x0A | R | | | Status of signals to and from SAMPA (updated every clock cycle) |- | | | | R | | [12:0] | Test data output from SAMPA |- | | | | R | | [16:13] | Serial out [3:0] |- | | | | R | | [18:17] | Number of serial out |- | | | | R | | [19] | Enable ZSU |- | | | | R | | [20] | Enable BC2 |- | | | | R | | [21] | Enable TCFU (deprecated) |- | | | | R | | [22] | Enable BC1 |- | | | | R | | [25:23] | Select test output |- | | | | R | | [26] | Select ADC0 or test input |- | | | | R | | [30:27] | Chip address |- | SMP_STS2 | [5:0] | 0x0B | R | | | Status of signals to and from SAMPA cont. |- | | | | R | | [0] | Slow control to SAMPA |- | | | | R | | [1] | Slow control from SAMPA |- | | | | R | | [2] | Reset_n |- | | | | R | | [3] | Event trigger |- | | | | R | | [4] | Heartbeat trigger |- | | | | R | | [5] | Sync signal |- | SMP_CFG | [13:0] | 0x0C | RW | | | SAMPA static signals, see SAMPA spec document for further details |- | | | | RW | 0x02 | [1:0] | Number of serial out |- | | | | RW | 0x00 | [2] | Enable ZSU |- | | | | RW | 0x00 | [3] | Enable BC2 |- | | | | RW | 0x01 | [4] | Enable TCFU |- | | | | RW | 0x01 | [5] | Enable BC1 |- | | | | RW | 0x03 | [8:6] | Select test output |- | | | | RW | 0x01 | [9] | Select ADC0 or test input |- | | | | RW | 0x01 | [13:10] | Chip address |- | SLVS_ERR | [15:0] | 0x0D | R | 0x00 | | SLVS errors detected |- | RAD_ERR | [31:0] | 0x0E | R | | | Errors detected in shiftregister test |- | | | | R | 0x00 | [15:0] | Bit 0 errors |- | | | | R | 0x00 | [31:16] | Bit 1 errors |- | VER | [31:0] | 0x0F | R | | | SVN version build was based on in dec |} Commands for command and control unit. {| class="wikitable" ! Value ! Description |- | 0x1 | Reset FPGA and SAMPA |- | 0x2 | Reset SAMPA |- | 0x3 | Send event trigger |- | 0x4 | Send heartbeat trigger |- | 0x5 | Send sync signal |- | 0x6 | Run readout of shiftregister once (RAD) |- | 0x7 | Reset errors in shiftregister count (RAD_ERR) |- | 0x8 | Execute slow control command |- | 0x9 | Reset HPS |} Test signals available for generation. {| class="wikitable" ! Value ! Description |- | 0x0 | Constant zeros |- | 0x1 | Sine wave, full wave, 512 samples pulse width |- | 0x2 | Saw wave, full wave, 512 samples pulse width |- | 0x3 | Triangle wave, full wave, 1024 samples pulse width |} == Data manager registers == The registers for the data manager module, located at address 0x0040 from the UART or 0xFF201000 from the HPS, is listed in table 4.4. {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | CNTRL | [7:0] | 0x00 | RW | 0x00 | | Control register |- | | | | RW | 0x00 | [0] | Enable acquisition |- | | | | RW | 0x00 | [7:1] | Reserved |- | PKT0 | [31:0] | 0x01 | R | 0x00 | [31:0] | Packets written to memory from channel 0 |- | PKT1 | [31:0] | 0x02 | R | 0x00 | [31:0] | Packets written to memory from channel 1 |- | PKT2 | [31:0] | 0x03 | R | 0x00 | [31:0] | Packets written to memory from channel 2 |- | PKT3 | [31:0] | 0x04 | R | 0x00 | [31:0] | Packets written to memory from test-input/ADC |- | FIFO0 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 0 |- | FIFO1 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 1 |- | FIFO2 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 2 |- | FIFO3 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 3 |} 26ed28ba4f2007f6bc248896c8a07c9707cf274e 2060 2059 2014-11-03T15:19:38Z Ave082 33 wikitext text/x-wiki = SAMPA DAQ Registers = == Command and Control module registers == The registers for the command and control module, located at address 0x0000 from the UART or 0xFF200000 from the HPS, is listed in table 4.1 {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | SC_ADD | [15:0] | 0x00 | RW | 0x00 | [4:0] | Slow control: Register address |- | | | | RW | 0x00 | [9:5] | Slow control: Channel address |- | | | | RW | 0x00 | [13:10] | Slow control: Chip address |- | | | | RW | 0x00 | [14] | Slow control: Broadcast |- | | | | RW | 0x00 | [15] | Slow control: Write/ not read |- | SC_DAT | [19:0] | 0x01 | RW | 0x00 | [19:0] | Slow control: Data to write |- | SC_MASK | [19:0] | 0x02 | RW | 0x00 | [19:0] | Slow control: Mask for writing * |- | CMD | [31:0] | 0x03 | RW | 0x00 | [15:0] | Commands, see table 4.2 |- | | | | RW | 0x00 | [31:15] | Loop count for commands |- | SC_RLT | [19:0] | 0x04 | R | 0x00 | [12:0] | Slow control: Response from SAMPA |- | SC_ERR | [1:0] | 0x05 | R | 0x00 | [0] | Error: Timeout waiting for response from slow control |- | | | | R | 0x00 | [1] | Error: Response from SAMPA not as expected |- | LNK_STS | [31:0] | 0x06 | R | 0x00 | [31:0] | Ethernet link status * |- | EVT_CFG | [31:0] | 0x07 | RW | 0x01 | [1:0] | Test signal output, see table 4.3 |- | | | | RW | 0x00 | [2] | Enable SLVS testing |- | | | | RW | 0x00 | [3] | Enable continuous readout of shiftregister |- | | | | RW | 0x00 | [31:3] | Reserved * |- | EVT_CNT | [31:0] | 0x08 | R | 0x00 | [31:0] | Reserved * |- | EV_BL | [31:0] | 0x09 | R | 0x00 | [31:0] | Reserved * |- | SMP_STS1 | [30:0] | 0x0A | R | | | Status of signals to and from SAMPA (updated every clock cycle) |- | | | | R | | [12:0] | Test data output from SAMPA |- | | | | R | | [16:13] | Serial out [3:0] |- | | | | R | | [18:17] | Number of serial out |- | | | | R | | [19] | Enable ZSU |- | | | | R | | [20] | Enable BC2 |- | | | | R | | [21] | Enable TCFU |- | | | | R | | [22] | Enable BC1 |- | | | | R | | [25:23] | Select test output |- | | | | R | | [26] | Select ADC0 or test input |- | | | | R | | [30:27] | Chip address |- | SMP_STS2 | [5:0] | 0x0B | R | | | Status of signals to and from SAMPA cont. |- | | | | R | | [0] | Slow control to SAMPA |- | | | | R | | [1] | Slow control from SAMPA |- | | | | R | | [2] | Reset_n |- | | | | R | | [3] | Event trigger |- | | | | R | | [4] | Heartbeat trigger |- | | | | R | | [5] | Sync signal |- | SMP_CFG | [13:0] | 0x0C | RW | | | SAMPA static signals, see SAMPA spec document for further details |- | | | | RW | 0x02 | [1:0] | Number of serial out |- | | | | RW | 0x00 | [2] | Enable ZSU |- | | | | RW | 0x00 | [3] | Enable BC2 |- | | | | RW | 0x01 | [4] | Enable TCFU |- | | | | RW | 0x01 | [5] | Enable BC1 |- | | | | RW | 0x03 | [8:6] | Select test output |- | | | | RW | 0x01 | [9] | Select ADC0 or test input |- | | | | RW | 0x01 | [13:10] | Chip address |- | SLVS_ERR | [15:0] | 0x0D | R | 0x00 | | SLVS errors detected |- | RAD_ERR | [31:0] | 0x0E | R | | | Errors detected in shiftregister test |- | | | | R | 0x00 | [15:0] | Bit 0 errors |- | | | | R | 0x00 | [31:16] | Bit 1 errors |- | VER | [31:0] | 0x0F | R | | | SVN version build was based on in dec |} Commands for command and control unit. {| class="wikitable" ! Value ! Description |- | 0x1 | Reset FPGA and SAMPA |- | 0x2 | Reset SAMPA |- | 0x3 | Send event trigger |- | 0x4 | Send heartbeat trigger |- | 0x5 | Send sync signal |- | 0x6 | Run readout of shiftregister once (RAD) |- | 0x7 | Reset errors in shiftregister count (RAD_ERR) |- | 0x8 | Execute slow control command |- | 0x9 | Reset HPS |} Test signals available for generation. {| class="wikitable" ! Value ! Description |- | 0x0 | Constant zeros |- | 0x1 | Sine wave, full wave, 512 samples pulse width |- | 0x2 | Saw wave, full wave, 512 samples pulse width |- | 0x3 | Triangle wave, full wave, 1024 samples pulse width |} == Data manager registers == The registers for the data manager module, located at address 0x0040 from the UART or 0xFF201000 from the HPS, is listed in table 4.4. {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | CNTRL | [7:0] | 0x00 | RW | 0x00 | | Control register |- | | | | RW | 0x00 | [0] | Enable acquisition |- | | | | RW | 0x00 | [7:1] | Reserved |- | PKT0 | [31:0] | 0x01 | R | 0x00 | [31:0] | Packets written to memory from channel 0 |- | PKT1 | [31:0] | 0x02 | R | 0x00 | [31:0] | Packets written to memory from channel 1 |- | PKT2 | [31:0] | 0x03 | R | 0x00 | [31:0] | Packets written to memory from channel 2 |- | PKT3 | [31:0] | 0x04 | R | 0x00 | [31:0] | Packets written to memory from test-input/ADC |- | FIFO0 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 0 |- | FIFO1 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 1 |- | FIFO2 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 2 |- | FIFO3 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 3 |} f5cbb27d18ebe5031361b2a0d1626947fd228f53 6 470 2071 2014-11-19T21:59:32Z Ave082 33 sampa MPW1 chip 3 wikitext text/x-wiki sampa MPW1 chip 3 30d63d4fa9d2644cbb3e054734268a97feb0abc4 0 467 2080 2079 2015-01-10T13:46:07Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====All latest files===== ;:;Download ;::*[[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 425cbb8a616cc68b15e1bb564ea74b6c18566136 2081 2080 2015-01-10T13:46:26Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] ==== Carrier boards ==== Comming == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====All latest files===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 576681ec1a400748e7ce3e692edd34b6e1f3e563 2083 2081 2015-01-29T14:11:16Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====All latest files===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 63===== Added basic run control to communicator and firmware. A set number of packets can be acquired. Fixed twos complement to ones complement conversion for ADC. System upgraded for Quartus 14.1 Kernel updated to 3.16 ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage. Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] be1efaa7d75c0d44ce5564de3201bcffd5cebc15 2084 2083 2015-01-29T14:12:31Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====All latest files===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage. Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 63===== Added basic run control to communicator and firmware. A set number of packets can be acquired. Fixed twos complement to ones complement conversion for ADC. System upgraded for Quartus 14.1 Kernel updated to 3.16 ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage. Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 121c91a02c7e64ab6d7da59a7ce49084521ddb82 2085 2084 2015-01-29T14:13:06Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====All latest files===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 63===== Added basic run control to communicator and firmware. A set number of packets can be acquired. Fixed twos complement to ones complement conversion for ADC. System upgraded for Quartus 14.1 Kernel updated to 3.16 ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] b91e4a99622b584a94b4c0cde4854d7238b33346 2086 2085 2015-01-29T14:14:20Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from =====All latest files===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card) (use save-as and remove extension .txt)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 63===== Added basic run control to communicator and firmware. A set number of packets can be acquired. Fixed twos complement to ones complement conversion for ADC. System upgraded for Quartus 14.1 Kernel updated to 3.16 ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card) (use save-as and remove extension .txt)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] ba1246f817f5a76ff2323f8accde6c4fd6c45e06 2087 2086 2015-01-29T14:18:11Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from If Windows renames the sampa_server or kernel with a .txt ending you need to remove this ending before copying the file to the memory card. =====All latest files===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 63===== Added basic run control to communicator and firmware. A set number of packets can be acquired. Fixed twos complement to ones complement conversion for ADC. System upgraded for Quartus 14.1 Kernel updated to 3.16 ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloadere (write to SD-card with dd/win32diskimager)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] e4606787833694e03eeb0b50f2a76833059b0a7f 2088 2087 2015-01-29T14:20:03Z Ave082 33 wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> ==== Analogue ==== [http://folk.uib.no/ave082/SAMPA/test_plan_chip01.pdf SAMPA MPW1 Chip 1 testplan and documentation] [http://folk.uib.no/ave082/SAMPA/test_plan_chip02.pdf SAMPA MPW1 Chip 2 testplan and documentation] ==== DSP ==== [http://folk.uib.no/ave082/SAMPA/SAMPA_MPW1_specs.pdf SAMPA MPW1 Chip 3 specifications] [http://folk.uib.no/ave082/SAMPA/heitor_graduation_project_SAMPA.pdf Heitor Guzzo Neves Thesis (DSP description)] == SAMPA DAQ Board Firmware and Software == ==== Source Code Repositories ==== [https://svnweb.cern.ch/cern/wsvn/SAMPA/ SAMPA SVN for web] [https://svn.cern.ch/reps/SAMPA/ SAMPA SVN for client] ==== Documentation ==== [http://folk.uib.no/ave082/SAMPA/DAQ_board_spec.pdf SAMPA DAQ board specifications] ====Registers==== See [[SAMPA/SAMPA Registers|SAMPA Registers]] for latest updated information on SAMPA registers. See [[SAMPA/SAMPA DAQ Registers|SAMPA DAQ Registers]] for latest updated information on SAMPA DAQ registers. ==== Compiled DAQ Firmware and Software Versions ==== The version is the same as the SVN version it was compiled from If Windows renames the sampa_server or kernel with a .txt ending you need to remove this ending before copying the file to the memory card. =====All latest files===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloader (write to SD-card with dd/win32diskimager)] =====Revision 63===== Added basic run control to communicator and firmware. A set number of packets can be acquired. Fixed twos complement to ones complement conversion for ADC. System upgraded for Quartus 14.1 Kernel updated to 3.16 ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=63&peg=63 SAMPA analyzer (ROOT code)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/zImage Kernel (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/socfpga.dtb devicetree (copy to SD-card)] ;::*[http://folk.uib.no/ave082/SAMPA/rev63/SoCKit_bootloader.img bootloader (write to SD-card with dd/win32diskimager)] =====Revision 59===== Added status register for ADC pins and a register for the version of the running sampa_server. Added root file generation for the analyser. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev59/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev59/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/24)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=59&peg=59 SAMPA analyzer (ROOT code)] =====Revision 55===== Fixed readout. Use SD Card from rev42 and add sampa_server. ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev55/sampa_server sampa_server program to be put on SD card] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_FPGA_test_board.jic FPGA firmware with internal SAMPA (controllable)] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev55/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/23)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=55&peg=55 SAMPA analyzer (ROOT code)] =====Revision 42===== ;:;Download ;::*[http://folk.uib.no/ave082/SAMPA/rev42/sockit.zip SD Card image] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board_w_sampa.jic FPGA firmware with internal SAMPA for testing] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_FPGA_test_board.jic FPGA firmware without internal SAMPA] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA%20communicator.exe SAMPA communicator] ;::*[http://folk.uib.no/ave082/SAMPA/rev42/SAMPA_analyzer.exe SAMPA analyzer (Windows binary) (ROOT 5.34/21)] ;::*[https://svnweb.cern.ch/cern/wsvn/SAMPA/testing/software/SAMPA_analyzer/SAMPA_analyzer.cpp?op=dl&rev=42&peg=42 SAMPA analyzer (ROOT code)] ==== Network fix ==== To set a fixed mac: Connect to terminal, warm reboot (key 6), press key in terminal to stop at uboot, type setenv ethaddr '7e:a5:87:ec:06:03' saveenv boot ==== Root compile problem ==== LNK1123: failure during conversion to COFF Install [http://www.microsoft.com/en-us/download/details.aspx?id=23691 VS2010 SP1] 82e504b32972c78adebc9c2e70e34c6e078058dd 0 33 2082 1726 2015-01-21T10:40:37Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cycloneiii /prog/altera/vhdl_libs/cycloneiii vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL]] [[http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide]] [[http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer]] [[http://bitvis.no/products/bitvis-utility-library/ Bitvis utility library]] [[Category:Mikroelektronikk]] e1e50f788e95908e7f57061d966535072daf310a 2096 2082 2015-03-18T10:57:29Z Nfyku 4 Changed from Cyclone III to Cyclone V wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cyclonev /prog/altera/vhdl_libs/cyclonev vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]] [[http://www.ashenden.com.au/ Ashenden Designs]] [[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]] [[http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)]] [[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]] [[http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL]] [[http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide]] [[http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer]] [[http://bitvis.no/products/bitvis-utility-library/ Bitvis utility library]] [[Category:Mikroelektronikk]] 74b49e66aaa889e633bbd5bcfcf63da40947c8a9 2097 2096 2015-03-18T10:58:48Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cyclonev /prog/altera/vhdl_libs/cyclonev vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] [http://www.ashenden.com.au/ Ashenden Designs] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] [http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [http://bitvis.no/products/bitvis-utility-library/ Bitvis utility library] [[Category:Mikroelektronikk]] 76b3ca8a37b65d15b86a3e496a872117e878b029 0 278 2089 2013 2015-03-05T12:18:54Z Ave082 33 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] 5a7cee1296d5317a6b335de33e9c4ff2af5e54ac 0 169 2090 1109 2015-03-05T12:48:33Z Ave082 33 wikitext text/x-wiki === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC_studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal. (Sjekk skrive stabilitet og lese stabilitet) # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. Sjekk LVS og DRC. === VHDL === Utfyllende tekst kommer [[Category:Mikroelektronikk]] 52c063eb80ceed0a696fbca61009e7479de18b8d 2091 2090 2015-03-05T12:49:20Z Ave082 33 wikitext text/x-wiki === Øving i bruk av IC Studio === Denne øvingen skal gi innblikk i bruken av [[IC_studio|IC Studio]] Du skal tegne en 6 transistor SRAM-celle med Bitline conditioning og write driver (kun 1 bit RAM). Bruk hierarkisk skjema, der hver hovedfunksjon har sitt underskjema. # Tegn skjema # Simulere og verifiser at RAM-cellen virker som den skal. (Sjekk skrivestabilitet og lesestabilitet) # Tegn utlegg for selve RAM-cellen. Pass på at den kan stables ved siden av identiske celler, slik at en NxM blokk RAM kan bygges opp. Sjekk LVS og DRC. === VHDL === Utfyllende tekst kommer [[Category:Mikroelektronikk]] b93586b33adaf944d6cf975300a1eeb12b1af7fa 0 34 2092 1095 2015-03-09T12:24:10Z Nfyku 4 Har endret litt på teksten ang. første gangs bruk wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa== '''Aller første gang''' man skal arbeide med Mentor Graphics verktøy skriv følgende kommando i et terminalvindu. <pre> ssh -X mikroserver3 /prog/design_kits/micro.init.csh </pre> Neste gang skriver man følgende i et teminalvindu: <pre> ssh -X mikroserver3 mentor questa </pre> kommandoen (aliaset) mentor sørger for velge riktige stier og miljøvariable. ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] 6030ab92438343a017471bfd9ebec546e9cc9ed6 0 35 2093 1093 2015-03-09T13:21:35Z Nfyku 4 wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> ssh -X mikroserver3 mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim -voptargs=+acc SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscillasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen. ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. 021811feb94477f617ec45a98008398d332e7223 0 410 2094 1808 2015-03-16T14:27:12Z Aoe033 85 wikitext text/x-wiki == XJDeveloper == Dette er ei innføring i XJDeveloper. Tilhøyrande dokumentasjon er meint brukt til XJDemo Board versjon 1.2. === Dokumentasjonsmappa === Dokumentasjonsmpappa inneheld: * Krinsskjema * Bilete av demokort v.1.2. * Demokort-netliste * Diverse test-filer * Device-filer === Sette opp kortet === Det fyrste som gjerast er å kople demokortet til datamaskina gjennom XJ Link. Bruk ein av USB-inngongane på baksida av maskina. Deretter må det lagast ei prosjektmappe, som skal innehalde alle filene som vert laga. Mappe-plasseringa speler inga rolle. For å starte XJDeveloper: start>Programs>XJTAG 2.4>XJDeveloper. Lag eit nytt prosjekt, og lagre det i prosjektmappa. Gje prosjektet namnet "demo". Når dette er gjort, dukker dialogboksen "Add board" automatisk opp. I denne boksen gjev du kortet namn, og du gjev XJDeveloper netlista til demokortet. Gje kortet namnet "XJDemo". Netlista finn du i dokumentasjonsmappa - demo.net I tillegg har vi ei BOM-fil, som gjev XJDeveloper tilleggsinformasjon om komponentane på kortet. Denne fila er ikkje strengt naudsynt, men er nyttig. I dokumentasjonen finn du BOM-fila - demo.bom Legg til BOM-fila under BOM-settings. Etter å ha trykka next, set du tredje kolonne til å vere "Device Reference", fjerne kolonne "Value", og siste kolonne til "Device Description". Save. Under Power/Ground Nets i Setup-menyen i venstre marg er det to nett, 3.3V og GND. Dra desse to neta over i riktig kolonne til høgre. No veit XJTAG kva nett som er power og jord, og vil ikkje forsøke å skrive til desse. ==== Identifisere komponentane ==== Neste steg er å identifisere JTAG-kjeden. Trykk på add i Chain Setup. Til høgre for TDI, trykker du på select og vel CN1, pin 5. Trykk OK. Så kjem IC2.B3 opp i Select Next Pin-vinduet. Dra denne ned i JTAG Devices-lista. Trykk på Browse, og velg fila med same namn som IC2, altså XC9536XL_cs48.bsd Gjer det same med IC3.1, 3032at44.bsd. Begge desse filene finst i dokumentasjonsmappa. Neste steget er ein resistor, R49. Dra denne ned i JTAG-Devices-lista, men velg Connect device i den øvste fana. Så vel du Create file. Namngje fila Resistor, og connect 1 til 2. Til slutt kjem IC1.13. Høgreklikk og set denne til TDO. Save. No har vi etablert JTAG-kjeden. Deretter skal vi kategorisere non-JTAG-devices. Under Categorise Devices-fana i venstremargen, finn vi alle komponentane(devices), og ingen er endå kategoriserte. * Risistorane som er markerte med "Suggested Series Resistors" kategoriserer vi som passive komponentar. Dra alle over i "Passive", og velg Resistor.pdd som allereie er laga. * Alle jumperane på krinsen lar vi og vere passive. Gje jumperane[1,2,3,5,6] namn [jumper1,jumper2,...,jumper6] når vi lager filer til desse. For jumper[1,2,3] ser vi frå krinsteikninga at desse er meint kopla. Kople difor pinane 1-2,3-4,5-6,7-8 for desse tre jumperane. Jumper5 og jumper6 skal vere opne. * Alle pull-resistorane kategoriserer vi óg som passive. Når vi skal lage PDD-filer for desse, gjer vi som ved serie-motstanden, bortsett frå at vi skiftar frå Connect->Pull. Connect 1-2. ** No er det dukka opp ein siste resistor, R26. Legg denne til i resistor.pdd. * Under Ignore Devices legg vi kondensatorane, connectorane og "Other Resistors". I tillegg legg vi Switch1 under ignore(denne kjem vi attende til). * Under Test Devices legg vi til IC4,IC5, alle diodane, SW2 og SW3. IC4 gjev vi namnet EEPROM, IC5 gjev vi namnet SRAM, diodane gjev vi namnet LED, SW2 gjev vi namnet pushbutton1 og SW3 gjev vi namnet pushbutton2. * Under Logic Devices legg vi IC1. Frå krinsteikninga finn vi kva komponent IC1 er, og gjev XJDeveloper informasjon om det. Det neste steget er å identifiserer tilkoplingspinnane. Under Pin Mapping ser vi JTAG connectoren. Frå krinsteikninga finn vi korleis denne skal bestemmast(CN1). Dei pinnane som ikkje er gjevne namn i krinsteikninga, lar vi vere "input". === Testing === Det siste steget er å klargjere for test. Under Run and Deploy, finn ein fana XJRunnet Setup. Velg New>Add Global Function>CONNTEST. Gje testen eit fornuftig namn. Save. For å køyre testane som er sett opp under XJRunner-fana, trykk på Run Test-fana, og køyr testen. Når vi tester, ser vi at vi får opp ein short mellom to "created" net på IC2. Desse to neta finst på krinsen, men er ikkje med i netlista. For å be XJDeveloper sjå vekk i frå denne feilen, kople dei to neta saman. Det kan gjerast under fana Connections i venstremargen. Trykk på Add, velg Pin to Pin, og kople dei to neta saman. For å komme unna problemet med at GP1 er stuck at 1/0, går vi inn på Constant Pins-fana og set denne pinen til anten High/Low. Hugs å fysisk sett brytaren SW1 anten High/Low. Viss alt er sett riktig opp, skal vi ikkje lenger få feilmeldingar når vi køyrer testen. For å gje oss høve til å lage feil, er kortet utstyrt med jumperar. Sjå på krinsteikninga, og lag stuck at 0/1, kortslutningsfeil og brotfeil. ==== Minnetest(SRAM) ==== XJDeveloper har laga ei fil SRAM.xje frå informasjonen vi har gjeve programmet. For å kunne bruke ein ferdiglaga, enkel minnestest, modifiserer vi denne fila til å passe med testen. I dokumentasjonsmappa finn du fila SRAM.txt. Erstatt innhaldet i SRAM.xje med SRAM.txt. Den første, og enkle, minnetesten, ligg lagra i dokumentasjonsmappa - SRAM_test.txt. Kopier innhaldet i denne fila, og lim det inn Test Editor. Test Editor er eit av vindauga under Test Device Files-fana i venstremargen. Save. Lag så ein ny test i XJRunner-fana. Velg Add Device Function>IC5>Test. Gje testen eit fornuftig namn. XJTAG har vedlagt demokortdokumentasjonen gjeve oss ein meir utfyllande minnetest. Denne er vedlagt i dokumentasjonsmappa, og heiter memtestSRAM.xje. For å bruke denne, høgreklikker vi på IC5 i Categorised Devices>Configure>Other Device File>SRAM_SOP24.xje. Dette legg automatisk memtestSRAM.xje til som tilleggskode. No kan testen køyrast på nytt. Bruk jumperane kring minnekrinsen til å lage feil. ==== Flash-test ==== Hvis du får opp følgende feilmelding under kjøring av flash-test: <span style="color:red"> memtestFlash.xje(148): Zero is an invalid argument to LOG. IC3.TestDestructive failed >>>> FAILED <<<< </span> Er dette fordi initialiseringsfunksjonen ''Init();'' ikke er inkludert i "Test Destructive"-funksjonen. Dette kan fikses ved å legge inn ''Init();'' manuelt i filen ''AMD_Flash.xje'', som du finner i XJDeveloper: Velg Test Device Files (Under fanen ''Setup'', til høyre i XJDeveloper) -> AMD Flash 48-Pin TSOP 4Mb x8.xje (Under fanen ''Navigator'') -> AMD_Flash.xje Bruk ctrl+F for søk og skriv inn "TestDestructive()". Skriv inn ''Init();'' rett under linjen ''result := RESULT_PASS'', og trykk lagre. For å gjennomføre Non-Destructive test må dette også gjøres i "TestNonDestructive()"-funksjonen i samme fil. ==== EEPROM-test ==== Vedlagt i dokumentasjonen er fila 24LC23A.xje. Dette er testfila til IC4 - EEPROM. Kopier innhaldet i 24LC23A.xje inn i "Test Editor" under EEPROM i venstremargs-fana Test Device Files. Save. Då får ein to feilmeldingar, fordi funksjonane testen refererer til manglar. Desse finst i IIC.xje, som òg ligg i dokumentasjonen. Under Additional Code Files legg du IIC.xje til EEPROM. Save. På same måte som for SRAM-testen, må vi lage ein EEPROM-test under XJRunner-fana. No kan du køyre testen på nytt. [[Category:Lagt til forklaring på feil i flash-test og forslag til retting.]] 0e2cabefbdf7949cb012858aee1be182100a2a62 0 36 2095 1742 2015-03-18T10:56:00Z Nfyku 4 Changed from Cyclone III to Cyclone V wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte synteseprogrammet: precision Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone V med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: vmap cyclonev /prog/altera/vhdl_libs/cyclonev Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] e9b07f7e392962169398d61947e81bc575721f6e 0 415 2098 2040 2015-04-07T22:19:52Z Ave082 33 wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths) Run "source europractice_installer.sh" and wait until done. Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang=tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </script> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh c4292b0b91d6bc4707cc24709ceb0e47e9148091 2099 2098 2015-04-07T22:23:21Z Ave082 33 wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths) Run "source europractice_installer.sh" and wait until done. Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang="tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </script> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh 02aea09a6b0a936bbd9eb8b3030e6ade46d721c1 2100 2099 2015-04-07T22:26:44Z Ave082 33 wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths){{-}} Run "source europractice_installer.sh" and wait until done.{{-}} Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang="tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </script> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh ln -s /prog/cadence/cadence_$YEAR\_init.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh 4f4a57d5b5b321561b35233b5cfaa3320019e4aa 2101 2100 2015-04-09T12:33:49Z Ave082 33 wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths){{-}} Run "source europractice_installer.sh" and wait until done.{{-}} Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang="tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </source> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh ln -s /prog/cadence/cadence_$YEAR\_init.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh 9af1517630dbbe11d205551f46750354f1ac3a22 2103 2101 2015-08-13T14:12:59Z Ave082 33 wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths){{-}} Run "source europractice_installer.sh" and wait until done.{{-}} Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang="tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </source> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh ln -s /prog/cadence/cadence_$YEAR\_init.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh *sysstat d29d3293b7d5d1e1e68148f38fd491b89cfb4e9f 8 471 2102 2015-06-29T12:30:16Z Mihho 3 Created page with "/* CSS placed here will be applied to all skins */ body.page-Main_Page h1.firstHeading { display:none; }" css text/css /* CSS placed here will be applied to all skins */ body.page-Main_Page h1.firstHeading { display:none; } 2f9ffedd9f1982bd8ddc1de01c138afb202d218e 0 38 2104 2048 2015-08-25T11:38:30Z Nfyku 4 /* Analog IC design flow using Cadence from basics(Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout) */ wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[Category:Mikroelektronikk]] b6130238441f4d73a9a7d26642157154db1e70ad 2125 2104 2015-10-27T09:24:17Z Ogr043 86 wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] = Simulation = [[Testbench|Virtuoso Testbench]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[Category:Mikroelektronikk]] fb71833a4002f7dc7b5a2ac6e5baafd2814b9c63 0 472 2105 2015-08-25T12:07:24Z Nfyku 4 Created page with "=Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design...." wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver3 tcsh The preferred shell is tcsh. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. First chose a parent directory, e.g. cd ~/ihp Copy the user environment design and set general Cadence environment variables by doing: cp -rp /prog/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/work/skel . source /prog/cadence/cadence_init.csh Change cshrc.cadence in ~/ihp/skel/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment source ~/ihp/skel/cds/cshrc.cadence Start the design tool virtuoso & [[Category:Mikroelektronikk]] 01927e2b9cf527a431e28bba738a2670366e7c6a 2106 2105 2015-08-25T12:09:08Z Nfyku 4 /* Cadence design with IHP 130nm process */ wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver3 tcsh The preferred shell is tcsh. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. First chose a parent directory, e.g. cd ~/ihp Copy the user environment design and set general Cadence environment variables by doing: cp -rp /prog/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/work/skel . source /prog/cadence/cadence_init.csh Change cshrc.cadence in ~/ihp/skel/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment source ~/ihp/skel/cds/cshrc.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation [[Category:Mikroelektronikk]] 48ddef1c2229f4b4a951849b8fa25f91f23bb046 0 466 2107 2047 2015-08-28T13:47:52Z Nfyku 4 wikitext text/x-wiki This script can be used to print the operating point parameters of all transistors in your design. Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a Debug Test with DC analysis: [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> The results file can also be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] [[Category:Mikroelektronikk]] 3d8d4b56269f9725310bce7efa9397ddbeffa5ce 2108 2107 2015-08-28T13:48:21Z Nfyku 4 wikitext text/x-wiki This script can be used to print the operating point parameters of all transistors in your design. Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a Debug Test with DC analysis: [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> The results file can also be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] [[Category:Mikroelektronikk]] 207adffd5916f145dd993b6c560390bc8112c39f 0 139 2109 1776 2015-09-09T07:34:37Z Nfyal 26 wikitext text/x-wiki == Seminar information == Our group meetings (some) are some at 10:15, on vidyo, look for specified category. Category "BERGEN SUSY and DM will be used as this meetings are already booked, but the subjects discussed will depend on the meeting and are pertinent to all HEPP project (High Energy Particle Physics) https://indico.cern.ch/category/2/ == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] Talks from Bergen in CERN indico (some of them visible only for ATLAS or ALICE members)<br> * Talks and events from UiB at CERN [https://indico.cern.ch/search.py?categId=0&p=bergen&f=&collections=&startDate=&endDate=&sortField=&sortOrder=d] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 87c515c041db87161f0bea66f652ae5e22501f42 2110 2109 2015-09-09T09:29:52Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are some at 10:15, on vidyo, look for specified category. Category "BERGEN SUSY and DM" will be used as this meetings are already booked, but the subjects discussed will depend on the meeting and are pertinent to all HEPP project (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] Talks from Bergen in CERN indico (some of them visible only for ATLAS or ALICE members)<br> * Talks and events from UiB at CERN [https://indico.cern.ch/search.py?categId=0&p=bergen&f=&collections=&startDate=&endDate=&sortField=&sortOrder=d] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] e3016b213752ce635f97a4c71f6da31d905098c9 2111 2110 2015-09-09T09:31:12Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Category "BERGEN SUSY and DM" will be used as this meetings are already booked, but the subjects discussed will depend on the meeting and are pertinent to all HEPP project (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] Talks from Bergen in CERN indico (some of them visible only for ATLAS or ALICE members)<br> * Talks and events from UiB at CERN [https://indico.cern.ch/search.py?categId=0&p=bergen&f=&collections=&startDate=&endDate=&sortField=&sortOrder=d] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] cc6d7cfb50620ef9343fb85b6b18fe403993ead6 2113 2111 2015-09-09T12:57:26Z Nfyal 26 /* Seminar and meeting information */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] Talks from Bergen in CERN indico (some of them visible only for ATLAS or ALICE members)<br> * Talks and events from UiB at CERN [https://indico.cern.ch/search.py?categId=0&p=bergen&f=&collections=&startDate=&endDate=&sortField=&sortOrder=d] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 1f9a18f0cb213a58f7b5334caed035e3caedb7d2 2114 2113 2015-09-09T13:31:22Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] cd3fb0ec28bac94760e03796712259be280fd2f7 2115 2114 2015-09-09T13:36:28Z Nfyal 26 Undo revision 2114 by [[Special:Contributions/Nfyal|Nfyal]] ([[User talk:Nfyal|talk]]) wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] Talks from Bergen in CERN indico (some of them visible only for ATLAS or ALICE members)<br> * Talks and events from UiB at CERN [https://indico.cern.ch/search.py?categId=0&p=bergen&f=&collections=&startDate=&endDate=&sortField=&sortOrder=d] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 1f9a18f0cb213a58f7b5334caed035e3caedb7d2 2116 2115 2015-09-09T13:39:10Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] cd3fb0ec28bac94760e03796712259be280fd2f7 2123 2116 2015-10-13T13:54:03Z Nfyal 26 /* Particle Physics Group Meetings/Seminars/Tutorials */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 65c6995b2dfb7debe28d079b198236383d3c8983 0 137 2112 2029 2015-09-09T12:54:32Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[From Higgs to Dark Matter 2014, in statu. nascendi, [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, there will be a PhD position in 2014, and PhD theory being announced now to start in 2015 all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 08/12/2009 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] a70e007d077d022655f504ffefc6c608a94c5eae 2117 2112 2015-09-25T21:50:29Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === Conferences === * [[From Higgs to Dark Matter 2014, in statu. nascendi, [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS is being evaluated now. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] ce47918107dd7a9d6f2f6f3381ebe09d986021f6 0 234 2118 2078 2015-09-25T21:52:55Z Nfyal 26 /* Theses, Notes, Publications, ... */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * For older theses try the old pages: [[http://www.uib.no/fg/subatom/prosjekter/atlas]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] 0931e02a28a53b654c9b2c14aa300c9910925c07 0 217 2119 2028 2015-10-09T07:32:47Z Nfyku 4 Added single transistor stage, fig. 9.18 wikitext text/x-wiki <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Only Cgd is considered (Zc) % Kjetil Ullaland ligning1='(Vout-Vgs)/Zc+gm*Vgs+Vout/Rl=0'; ligning2='(Vgs-Vout)/Zc+(Vgs-Vin)/Rs=0'; ligning1=subs(ligning1,'1/(j*w*C)','Zc'); ligning2=subs(ligning2,'1/(j*w*C)','Zc'); pretty(ligning1); pretty(ligning2); disp('Solve for Vgs'); vgs_solved=solve(ligning2,'Vgs'); pretty(simplify(vgs_solved)); disp('Solve for Vout(vin)'); ligning3=subs(ligning1,vgs_solved,'Vgs'); Vout_solved=solve(ligning3,'Vout'); pretty(simplify(Vout_solved)) </pre> <pre> % Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 % to find Vo as a function of Is % Kjetil Ullaland, 2015 syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz; eq1=sym('(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=simplify(subs(eq1,V1,solV1)); SolVo=simplify(solve(eq3,[Vo])); pretty(simplify(SolVo/Is)); </pre> fb0cffe8b6df7bddf47c517d213629eb19d59295 2120 2119 2015-10-09T07:37:02Z Nfyku 4 Nfyku moved page [[Nodeligninger for en source-følger]] to [[Symbolsk løsning av nodeligninger med Matlab]] without leaving a redirect wikitext text/x-wiki <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Only Cgd is considered (Zc) % Kjetil Ullaland ligning1='(Vout-Vgs)/Zc+gm*Vgs+Vout/Rl=0'; ligning2='(Vgs-Vout)/Zc+(Vgs-Vin)/Rs=0'; ligning1=subs(ligning1,'1/(j*w*C)','Zc'); ligning2=subs(ligning2,'1/(j*w*C)','Zc'); pretty(ligning1); pretty(ligning2); disp('Solve for Vgs'); vgs_solved=solve(ligning2,'Vgs'); pretty(simplify(vgs_solved)); disp('Solve for Vout(vin)'); ligning3=subs(ligning1,vgs_solved,'Vgs'); Vout_solved=solve(ligning3,'Vout'); pretty(simplify(Vout_solved)) </pre> <pre> % Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 % to find Vo as a function of Is % Kjetil Ullaland, 2015 syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz; eq1=sym('(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=simplify(subs(eq1,V1,solV1)); SolVo=simplify(solve(eq3,[Vo])); pretty(simplify(SolVo/Is)); </pre> fb0cffe8b6df7bddf47c517d213629eb19d59295 2122 2120 2015-10-09T07:58:46Z Nfyku 4 wikitext text/x-wiki === Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin === <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vout as a function of Vin % Only Cgd is considered (Zc) % Kjetil Ullaland ligning1='(Vout-Vgs)/Zc+gm*Vgs+Vout/Rl=0'; ligning2='(Vgs-Vout)/Zc+(Vgs-Vin)/Rs=0'; ligning1=subs(ligning1,'1/(j*w*C)','Zc'); ligning2=subs(ligning2,'1/(j*w*C)','Zc'); pretty(ligning1); pretty(ligning2); disp('Solve for Vgs'); vgs_solved=solve(ligning2,'Vgs'); pretty(simplify(vgs_solved)); disp('Solve for Vout(vin)'); ligning3=subs(ligning1,vgs_solved,'Vgs'); Vout_solved=solve(ligning3,'Vout'); pretty(simplify(Vout_solved)) </pre> === Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is === <pre> % Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 % to find Vo as a function of Is % Kjetil Ullaland, 2015 syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz; %% With feedforward capacitor eq1=sym('(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/Zc+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=subs(eq1,V1,solV1); SolVo=simplify(solve(eq3,[Vo])); disp('With capacitor only in feedforward loop'); pretty(simplify(SolVo/Is)); %% With series resistor and capacitor in feedforward loop eq1=sym('(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=simplify(subs(eq1,V1,solV1)); SolVo=solve(eq3,[Vo]); disp('With series resistor and capacitor in feedforward loop'); pretty(simplify(SolVo/Is)); </pre> 6fed37fc1f8960bdf3c0c14aeaa1dff9bc6fc8b0 0 202 2121 2026 2015-10-09T07:41:32Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [http://www.k-state.edu/ksuedl/publications/Technote%201%20-%20Equivalent%20Noise%20Bandwidth.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf Elementary Physics of P-N Junctions]] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 86d59e8cd8621662fbc84112f8d7404440c9e934 0 154 2124 366 2015-10-15T09:41:08Z Nfyku 4 wikitext text/x-wiki IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte sysops-rettigheter for å kunne opprette eller redigere sider. Noen brukere (Bureaucrats) kan gi slike rettigheter. Ta kontakt med en av dem hvis du trenger editeringsrettigheter. Husk å logge inn før du spør om slike rettigheter. * [http://www.uib.no/personer/Kjetil.Heitmann Kjetil Heitmann] * [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] * [http://www.uib.no/personer/Nikolai.Ostgaard Nikolai Østgaard] ---- <references/> [[Category:Tips and Tricks]] ae3f0729b28b97babfe8efaab4fe57509cc3d540 6 473 2126 2015-10-27T09:30:29Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 474 2127 2015-10-27T09:42:21Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2128 2127 2015-10-27T09:43:22Z Ogr043 86 Ogr043 uploaded a new version of [[File:Screenshot from 2015-10-27 10-38-37.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 475 2129 2015-10-27T09:44:03Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 476 2130 2015-10-27T09:48:24Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 477 2131 2015-10-27T09:54:39Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 478 2132 2015-10-27T09:55:10Z Ogr043 86 Created page with "= Simulate with corner cases = To simulate with the corner cases in the fabrication process you have to add the corner files provided in the design kit. File:Selection_001..." wikitext text/x-wiki = Simulate with corner cases = To simulate with the corner cases in the fabrication process you have to add the corner files provided in the design kit. [[File:Selection_001.png|200px]] Choose "Click to add corner" "Click to add" the model files you need. Ex. The corner files for the MOS transistor in IHP130nm process is located in $IHP_TECH/tech/SG13_MOS/library/spectre/cornerMOSlv_psp.scs After adding the model files needed proceed by adding multiple corners: [[File:corner.png|400px]] The model files contains sections with the different corners. Choose sections and make sure you enable the section "tick box" and name the corner with a corresponding name: [[File:sections.png|400px]] The corners setup also makes it possible to simulate for different temperatures or design variables like VDD and transistor length. Ex. test for three different temperatures with comma as separation: -20,30,80 [[File:complete.png|400px]] e0e14149454531724c1a85540b3a4abe36bb62ec 0 139 2133 2123 2015-11-17T17:21:03Z Nfyal 26 /* Seminar and meeting information */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 388740305fea988cb584cd1b8d15b55f3cab5d3b 2134 2133 2015-11-17T17:22:07Z Nfyal 26 /* Seminar and meeting information */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 65c6995b2dfb7debe28d079b198236383d3c8983 2135 2134 2015-11-17T17:22:24Z Nfyal 26 /* 2015 */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 81db6232d406ee65720b7b2a42ca605635dd4a80 2136 2135 2015-11-27T07:29:50Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 10:15, on vidyo, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/2/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2016 === Nordic b-annual particle physics meeting, please register before 15 december and book your hotel before 1st of December: http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 0fd22a9ff36110deb0d55aa39c45b1823bd144b4 0 278 2137 2089 2015-12-11T18:52:07Z Ogr043 86 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Installation, board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] [[Category:Mikroelektronikk]] 108ae0d2f0c23b8830eea84336c2ba7e8c415a09 2138 2137 2015-12-11T19:09:08Z Ogr043 86 /* Digilent Nexys 4 */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] [[Category:Mikroelektronikk]] bdb77e15c4cf45b5a4bb9b43493a115429d3fcb9 2 479 2139 2016-01-20T11:45:21Z Nfyal 26 Created page with "Here is page of Nikolai Fomin." wikitext text/x-wiki Here is page of Nikolai Fomin. 411e90d65abc99d5b3ce5fa1d372d63b539435ce 0 25 2140 1997 2016-01-26T12:31:48Z Ogr043 86 wikitext text/x-wiki == Mikroelektronikk == Dokumentasjon for Mentor Graphics IC-programvaren finnes i katalogen /prog/mentor/icflow_2008_1/2008.1_rhelx86linux/icflow_home/shared/pdfdocs eller ../htmldocs/ . Bruk * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[Bitvis UVVM VHDL Verification Component Framework]] * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven * [[SmartFusion2]] Oppsett og design med SF2 * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus [[Category:Mikroelektronikk]] e1e75766861baff9f3e3e0a8a1b15df54dfa0bb2 6 480 2141 2016-01-26T13:02:50Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2143 2141 2016-01-26T13:03:43Z Ogr043 86 Ogr043 uploaded a new version of [[File:Screenshot from 2016-01-26 14-02-13.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2144 2143 2016-01-26T13:04:16Z Ogr043 86 Ogr043 uploaded a new version of [[File:Screenshot from 2016-01-26 14-02-13.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 481 2142 2016-01-26T13:03:14Z Ogr043 86 Created page with "=== Introduction === Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete co..." wikitext text/x-wiki === Introduction === Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's included? === [[File:Screenshot from 2016-01-26 14:02:13.png|400px]] af9a5c1c2d455312640c58f71a15bf54d23a9c4d 2145 2142 2016-01-26T13:08:20Z Ogr043 86 wikitext text/x-wiki === Introduction === Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's included? === bcb19dc81cc8fdea45d7f360e10e5e64fadb3147 2147 2145 2016-01-26T13:11:12Z Ogr043 86 /* What's included? */ wikitext text/x-wiki === Introduction === Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's included? === [[File:Screenshot from 2016-01-26 14:08:42.png|thumb]] 361c03aae92c4f7ad3df2f86b8fcec8e3193f3f6 2152 2147 2016-01-26T14:04:25Z Ogr043 86 incl wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> === Introduction === Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === Let's create our own testbench for the IRQC === Copy the bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. Open up bitvis_irqc/tb/irqc_tb.vhd and delete it! Let's start over.... <pre> -- Add the standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; library STD; use std.env.all; --Also add the Bitvis UVVM Utility Library library uvvm_util; context uvvm_util.uvvm_util_context; --And the Verification IP for the simple bus interface library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; --And the design's package file use work.irqc_pif_pkg.all; </pre> Copy the bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. We can start trying out the example testbench before continuing. Open up Questa/Modelsim. Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 45f18eb0f077d53a4720ac51bf509b507174e212 2153 2152 2016-01-26T14:09:27Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === Let's create our own testbench for the IRQC === Copy the bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. Open up bitvis_irqc/tb/irqc_tb.vhd and delete the content! Let's start over.... <pre> -- Add the standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; library STD; use std.env.all; --Also add the Bitvis UVVM Utility Library library uvvm_util; context uvvm_util.uvvm_util_context; --And the Verification IP for the simple bus interface library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; --And the design's package file use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); begin -- HERE YOU WILL PUT THE REST OF THE CODE! end func; </pre> ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 7b2c7646061a6237cb8cd9872aa41f04e6fca406 2154 2153 2016-01-26T14:10:09Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials == Testbench creation == Copy the bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. Open up bitvis_irqc/tb/irqc_tb.vhd and delete the content! Let's start over.... <pre> -- Add the standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; library STD; use std.env.all; --Also add the Bitvis UVVM Utility Library library uvvm_util; context uvvm_util.uvvm_util_context; --And the Verification IP for the simple bus interface library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; --And the design's package file use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); begin -- HERE YOU WILL PUT THE REST OF THE CODE! end func; </pre> ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 9bb44a64af800e729daab239cca8e225bebf0108 2155 2154 2016-01-26T14:36:51Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === The provided interrupt controller is == Testbench creation == === Generate TB entity === === Add support process for clock generation === === Add test sequencer process === Copy the bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 4a289b20bc925ce3fecca3036e36d04388a4b477 2158 2155 2016-01-26T14:56:03Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == === Generate TB entity === === Add support process for clock generation === === Add test sequencer process === Copy the bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 9f8aa914460cc991175b69c8f044c5358442da7f 2159 2158 2016-01-26T15:11:39Z Ogr043 86 /* Testbench creation */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] Copy the bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. == Testbench creation == === Generate TB entity === === Add support process for clock generation === === Add test sequencer process === ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 3a0b061a041b9079e096799f33617c81d55b695f 2160 2159 2016-01-26T15:12:15Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity === === Add support process for clock generation === === Add test sequencer process === ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 47c38361f021e9e57fa0fff3f1582884366f012a 2161 2160 2016-01-27T13:46:48Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity === <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === === Add test sequencer process === ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 85b311f0c13d25c3635f613c50f68fc1dec1b394 2162 2161 2016-01-27T13:56:29Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === === Add test sequencer process === ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> b9652415f88ad4cdba4c10c6c8359a4a68602b49 2163 2162 2016-01-27T14:11:34Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> clock_gen(clk, clock_ena, 10 ns); clock_ena <= true; </pre> === Add test sequencer process === ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> 2b22ce4d7592f34549ad1f52b3dc5b9a203ea488 2164 2163 2016-01-27T14:14:41Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> clock_gen(clk, clock_ena, C_CLK_PERIOD); clock_ena <= true; </pre> === Add test sequencer process === ==Open up Questa/Modelsim== Change directory to the script folder (obviously change to your folder.....): <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> a59d06bc7b5078b61c3d7dd2717ce0cc169f7859 2165 2164 2016-01-27T15:08:13Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting this out will result in no log whatsoever... ce1a518747b4644e9f1af3bcdac839ac922e34b9 2166 2165 2016-01-27T15:14:46Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == 3f81991cc57423af94da5c2982f679e2b72ef5b9 2167 2166 2016-01-27T15:51:51Z Ogr043 86 /* Verbosity control */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. 86157ce94d27da4debf05aff8a1fde524f2c14a0 2168 2167 2016-01-27T15:52:43Z Ogr043 86 /* Verbosity control */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. 6f312183ef58bab64c94b1043531b8be89378e2b 2169 2168 2016-01-28T11:16:33Z Ogr043 86 /* Verbosity control */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == 56b5bd836c106050970c2cd42fc07e0ba284eaa4 2170 2169 2016-01-28T11:53:50Z Ogr043 86 /* Implement first tests */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intention. These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); </pre> b76235a97da87bd6b4de8557f8aa9df94adad74c 2172 2170 2016-01-28T11:55:09Z Ogr043 86 /* Implement first tests */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intention. These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); </pre> 63dbc0417592bc73fbfdf7907a7ea9c813ec73db 2173 2172 2016-01-28T12:06:30Z Ogr043 86 /* Implement first tests */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefor can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> 1dc16449f0796489bbc840b5648f24c3f5464f94 2175 2173 2016-01-28T13:02:21Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|300px]] 8e5d6bad53285a55014172c71fa6b91e5b7814a4 2176 2175 2016-01-28T13:03:12Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|600px]] 8d8b56070296e962ad236fb31a02c080e4e2c726 2177 2176 2016-01-28T13:03:33Z Ogr043 86 /* Implement first tests */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] 872565a96c613a15d09b21151f7d7f7987971efb 2178 2177 2016-01-28T13:11:59Z Ogr043 86 /* Implement first tests */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> a7ebd2486506b26c60df85ed86f2186c12f3954f 6 482 2146 2016-01-26T13:09:32Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2148 2146 2016-01-26T13:11:40Z Ogr043 86 Ogr043 uploaded a new version of [[File:Screenshot from 2016-01-26 14-08-42.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 483 2149 2016-01-26T13:12:15Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 484 2150 2016-01-26T13:13:58Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 160 2151 722 2016-01-26T13:24:35Z Nfyal 26 /* Upcoming tutorials */ wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[Software workshop, 09/09-09]] == Upcoming tutorials == ATLAS analysis tutorial, 7-8 February 2016, Oslo https://indico.cern.ch/event/472469/overview == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] f342d470e2ca1b9c854cd13ff09914a53158cddf 6 485 2156 2016-01-26T14:52:05Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 486 2157 2016-01-26T14:55:01Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 487 2171 2016-01-28T11:54:58Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 488 2174 2016-01-28T13:01:56Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 489 2179 2016-01-28T13:14:02Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 481 2180 2178 2016-01-28T13:28:04Z Ogr043 86 /* Implement first tests */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms? == 7c7cbb638c314e547f750c9f6ecb36ed3443a0ff 2181 2180 2016-01-28T13:59:38Z Ogr043 86 /* Subprograms? */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> 586f9fca0386ddb3704f6fec23f799f237ab3e6c 2182 2181 2016-01-28T14:04:06Z Ogr043 86 /* Register access */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this to: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at high level. == 568828c75aac9f74a092c559ed9f2cb108d68d9c 2184 2182 2016-01-28T14:06:18Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this to: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. [[File:bfm.png|550px]] == 871718b8c8098a8185d50166953dcef4686d6690 2185 2184 2016-01-28T14:30:20Z Ogr043 86 /* Register access */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> 351d124622a28c004a4b028788e1aa5b245865e1 2186 2185 2016-01-28T14:40:28Z Ogr043 86 /* Subprograms */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> 7e68d70338a08b79162d7b5eadd176ed42f39139 2189 2186 2016-01-28T14:44:41Z Ogr043 86 /* Checking register write and read */ wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|400px]] However, if there's an error: [[File:error2.png|400px]] fea636cd9b9a73a71ca0a4e84b5aea666d0b6dda 2190 2189 2016-01-28T15:02:15Z Ogr043 86 wikitext text/x-wiki <pre> -- Copyright (c) 2016 by Bitvis AS. All rights reserved. -- You should have received a copy of the license file containing the MIT License (see LICENSE.TXT), if not, -- contact Bitvis AS <support@bitvis.no>. -- UVVM AND ANY PART THEREOF ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -- IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH UVVM. --======================================================================================================================== </pre> This wiki page steals heavily from the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here]. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] 088959e8bd1fc661871246c0c29365f0b6093540 2191 2190 2016-01-28T15:16:06Z Ogr043 86 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref name=UVVM /> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == UVVM LICENCE AGREEMENT == {{reflist|refs=<ref name=UVVM>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> }} 12cb38ee8ef27f23a9dfa6739d121aee6390864c 2192 2191 2016-01-28T15:16:55Z Ogr043 86 /* UVVM LICENCE AGREEMENT */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref name=UVVM /> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == UVVM LICENCE AGREEMENT == {{reflist|refs=<ref name=UVVM>Test</ref> }} fb138679d1c92cc3f9a32819e271dee006cfa017 2193 2192 2016-01-28T15:18:21Z Ogr043 86 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref name=UVVM /> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == UVVM LICENCE AGREEMENT == {{reflist| refs= <ref name=UVVM>This is the jukeboxes reference.</ref> }} f91f299731124b3c413c64037320eefb85e29d7c 2194 2193 2016-01-28T15:20:54Z Ogr043 86 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>''LibreOffice For Starters'', First Edition, Flexible Minds, Manchester, 2002, p. 18</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == UVVM LICENCE AGREEMENT == {{reflist}} 9f666327ba047c4a7515ac8bea6910ec11402795 2195 2194 2016-01-28T15:21:22Z Ogr043 86 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Libraries used for string handling in UVVM library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == UVVM LICENCE AGREEMENT == {{reflist}} 5793b096d6243c2ab5bdf77207ff472664d81e0c 2196 2195 2016-01-29T07:38:27Z Ogr043 86 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == UVVM LICENCE AGREEMENT == {{reflist}} b53faac8270f886c6f29d04d1906528c76e5c44e 2197 2196 2016-02-02T09:17:29Z Ogr043 86 /* Checking register write and read */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM LICENCE AGREEMENT == {{reflist}} 640ace23616e9cd29cfe0399584845004ce9d42d 2198 2197 2016-02-02T09:20:12Z Ogr043 86 /* Check stable */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM LICENCE AGREEMENT == {{reflist}} bf5fe179fdf09f93e1085ffc96831f6a145b7331 2199 2198 2016-02-02T09:20:26Z Ogr043 86 /* Check stable */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM LICENCE AGREEMENT == {{reflist}} c6876ce1c05b13dffc332d249afeaf6d2a8e3914 2200 2199 2016-02-02T11:19:07Z Ogr043 86 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM LICENCE AGREEMENT == {{reflist}} 154b5842754cc96e60759e49616509171eed17b9 2201 2200 2016-02-02T11:19:26Z Ogr043 86 /* UVVM Utility Library Testbench creation */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM LICENCE AGREEMENT == {{reflist}} 061a97a402f4633887df9b5c0df4c77d5bba025b 2202 2201 2016-02-02T11:20:23Z Ogr043 86 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} 1fc0909333530e224e03c6f3823344e83f025122 2203 2202 2016-02-02T12:22:56Z Ogr043 86 /* Register access */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} fea490d7ef46b29cec1dd5f4cd960a72fe47d638 6 490 2183 2016-01-28T14:05:53Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 491 2187 2016-01-28T14:43:10Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 492 2188 2016-01-28T14:44:35Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 278 2204 2138 2016-03-02T21:39:57Z Nas005 92 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== [[Category:Mikroelektronikk]] ec4c95cbcb29a83f4d28ca9a24e7ee692c51beec 2205 2204 2016-03-02T21:40:33Z Nas005 92 /* Vivado 2015.4 Install with free licens */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== == gh == [[Category:Mikroelektronikk]] 8b12970a8ce7bef9154968ac114d64fd54a58e1d 2206 2205 2016-03-02T21:41:14Z Nas005 92 /* gh */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== [[Category:Mikroelektronikk]] e624066e12e9a6832818b99a2a14ede66b2b75b6 2207 2206 2016-03-02T21:42:14Z Nas005 92 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== sdsasdad [[Category:Mikroelektronikk]] e884dba11083ec4ac715bd338ea0f22c17c89035 2208 2207 2016-03-02T21:42:30Z Nas005 92 /* Vivado 2015.4 Install with free licens */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== [[Category:Mikroelektronikk]] ec4c95cbcb29a83f4d28ca9a24e7ee692c51beec 2209 2208 2016-03-02T21:46:46Z Nas005 92 /* Vivado 2015.4 Install with free licens */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== * Install [[Category:Mikroelektronikk]] 0f519f61f326cd32c82496d901e66a6b732fef76 2221 2209 2016-03-02T22:13:29Z Nas005 92 /* Vivado 2015.4 Install with free licens */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== == Introkusjon == To download Vivado for free you must first create an account. By following this link [http://www.xilinx.com/support/download.html/ Xilinx web page] you will enter Xilinx download page. For this tutorial we will be using the 2015.4 version. To download for Windows Vivado HLx 2015.4 Web Install for Windows with SDK (EXE - 49.32 MB) For linux Vivado HLx 2015.4 Web Install for Linux with SDK (BIN - 76.98 MB) Run the installer and this will show, press next [[File:1.png]] Type your user name and password and press next [[File:2.png]] Agree to everything!!! Or else?!?! [[File:3.png]] Choose Vivado HL WebPACK [[File:4.png]] Make sure the Software Development Kit, Artix-7, Install Cable Drivers, and Acquire or Manage a License Key are all checked and click next. The DocNav file is not necessary but it allows you to • Find answers to your questions quickly through the integrated search • Manage documents on your desktop through the Download Manager • Always ensures you are reading the latest version of documentation Detailed information about using the tool and its features can be found in the Online Help Menu which you can access after installation. [[File:5.png]] [[File:6.png]] [[File:7.png]] [[File:8.png]] Choose a directory to Install you Vivado product, make sure you have adequate free space on your hard drive. The final screen summarizes your selections. Click install, and the installer will begin downloading the files it needs to install Vivado. When it is done this screen will pop up. Click ok and the license manager should open up. If not open Vivado press Help=>obtain a license key and this window will open. Choose “Get Free SDK, Vivado WebPACK” and then press Connect Now. . You will be redirected to Xilinx home page were you will need to sign in with user name and password. After clicking “sign in”, press “next” and this site will pop up Choose “Vivado Design Suite: HL WebPACK, Node-Locked License……..” and press Generate Node-Locked License. Next this window will pop up. Click next and a new window will pop up, click next again and this will show Open your E-mail and download the attached Xilinx.lic file. When you go back to the license manager this will show, press cancel. Go to Load License in the left menu. You should see this Click Copy License and upload the Xilinx.lic file and you will get this message If you now press the view license status in the left menu, you should see this You can now close the license manager and Vivado is good to go. CREATING NEW PROJECT Press create new project Press next on the first window that pops up, then you can choose were you want to store your project, click next. Choose RTL project and click next Add your VHDL file if you have one, if you don’t you can add the VGA-controller file just to make sure that everything works properly. Click next Click next Add the Nexys4_Master.xdc , this will connect all your I/O, LED, SW etc. Choose the xca100tcsg324-1 and click next and then finish. Vivado will open, now you can make your own VHDL code or you can follow instruction further if you want to use the VGA controller. If you want to make your own code you can skip the IP part and go to generate bitstream to see how you should implement your code on the FPGA. Adding IP’s, clk generator 25.2MHz and BRAM. Click IP Catalog and then Search for Clocking Wizard and enter and this will pop up, clocking option should look like this, remember to change the Component name! Change the output clock to 25.2MHz Port renaming: use names that explains your component, and click OK This should pop up, click generate Adding BRAM, search for bram and enter the Block Memory Generator and this should pop up. Remember component name Port A Options, write width = 12bits, write depth = 307200=(480*640 pixels projected on screen), then click OK and then generate as before and wait until the synthesis is done. GENERATE BITSTREAM: click generate bitstream If this pops up click yes If this message shows, just click ok, it only means that you have pins activated in your Nexys4_Master.xdc that are not in use. If later on want to change witch pins are active on your board you can configure this by entering the Nexys4_Master.xdc When completed, choose “Open Hardware Manager” and click ok At this point connect your NEXY4 board . In the left menu under “program and debug”, click open target => open new target Open new Hardware target will pop up, click next two times and this will show. Choose JTAG clock freq. 30 000 000, click next and then finish Now you can program your device, click program device and choose your FPGA Click program and your device is ready to go. [[Category:Mikroelektronikk]] 963c2abefc93070b09f4d8d9d19481c8fd420ba4 2222 2221 2016-03-02T22:16:08Z Nas005 92 /* Introkusjon */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== * [[Install]] To download Vivado for free you must first create an account. By following this link [http://www.xilinx.com/support/download.html/ Xilinx web page] you will enter Xilinx download page. For this tutorial we will be using the 2015.4 version. To download for Windows Vivado HLx 2015.4 Web Install for Windows with SDK (EXE - 49.32 MB) For linux Vivado HLx 2015.4 Web Install for Linux with SDK (BIN - 76.98 MB) Run the installer and this will show, press next [[File:1.png]] Type your user name and password and press next [[File:2.png]] Agree to everything!!! Or else?!?! [[File:3.png]] Choose Vivado HL WebPACK [[File:4.png]] Make sure the Software Development Kit, Artix-7, Install Cable Drivers, and Acquire or Manage a License Key are all checked and click next. The DocNav file is not necessary but it allows you to • Find answers to your questions quickly through the integrated search • Manage documents on your desktop through the Download Manager • Always ensures you are reading the latest version of documentation Detailed information about using the tool and its features can be found in the Online Help Menu which you can access after installation. [[File:5.png]] [[File:6.png]] [[File:7.png]] [[File:8.png]] Choose a directory to Install you Vivado product, make sure you have adequate free space on your hard drive. The final screen summarizes your selections. Click install, and the installer will begin downloading the files it needs to install Vivado. When it is done this screen will pop up. Click ok and the license manager should open up. If not open Vivado press Help=>obtain a license key and this window will open. Choose “Get Free SDK, Vivado WebPACK” and then press Connect Now. . You will be redirected to Xilinx home page were you will need to sign in with user name and password. After clicking “sign in”, press “next” and this site will pop up Choose “Vivado Design Suite: HL WebPACK, Node-Locked License……..” and press Generate Node-Locked License. Next this window will pop up. Click next and a new window will pop up, click next again and this will show Open your E-mail and download the attached Xilinx.lic file. When you go back to the license manager this will show, press cancel. Go to Load License in the left menu. You should see this Click Copy License and upload the Xilinx.lic file and you will get this message If you now press the view license status in the left menu, you should see this You can now close the license manager and Vivado is good to go. CREATING NEW PROJECT Press create new project Press next on the first window that pops up, then you can choose were you want to store your project, click next. Choose RTL project and click next Add your VHDL file if you have one, if you don’t you can add the VGA-controller file just to make sure that everything works properly. Click next Click next Add the Nexys4_Master.xdc , this will connect all your I/O, LED, SW etc. Choose the xca100tcsg324-1 and click next and then finish. Vivado will open, now you can make your own VHDL code or you can follow instruction further if you want to use the VGA controller. If you want to make your own code you can skip the IP part and go to generate bitstream to see how you should implement your code on the FPGA. Adding IP’s, clk generator 25.2MHz and BRAM. Click IP Catalog and then Search for Clocking Wizard and enter and this will pop up, clocking option should look like this, remember to change the Component name! Change the output clock to 25.2MHz Port renaming: use names that explains your component, and click OK This should pop up, click generate Adding BRAM, search for bram and enter the Block Memory Generator and this should pop up. Remember component name Port A Options, write width = 12bits, write depth = 307200=(480*640 pixels projected on screen), then click OK and then generate as before and wait until the synthesis is done. GENERATE BITSTREAM: click generate bitstream If this pops up click yes If this message shows, just click ok, it only means that you have pins activated in your Nexys4_Master.xdc that are not in use. If later on want to change witch pins are active on your board you can configure this by entering the Nexys4_Master.xdc When completed, choose “Open Hardware Manager” and click ok At this point connect your NEXY4 board . In the left menu under “program and debug”, click open target => open new target Open new Hardware target will pop up, click next two times and this will show. Choose JTAG clock freq. 30 000 000, click next and then finish Now you can program your device, click program device and choose your FPGA Click program and your device is ready to go. [[Category:Mikroelektronikk]] 96a86455df8155ef4ea2173c981425a7bb701986 2224 2222 2016-03-02T22:17:54Z Nas005 92 /* Vivado 2015.4 Install with free licens */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Vivado 2015.4 Install with free licens ==== * [[Install]] [[Category:Mikroelektronikk]] d0635788b79302b6f0c77768ef36f4590f8e98ec 2225 2224 2016-03-02T22:32:08Z Nas005 92 /* Vivado 2015.4 Install with free licens */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] === Øvingsoppgaver === [[Øvingsoppgaver PHYS321]] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Using Vivado ==== * [[Install Vivado 2015.4 with free licens]] * [[VGA controller VHDL code]] * [[Nexys4_Master.xdc]] * [[Using the VGA controller with block ram generator and clock wizard]] [[Category:Mikroelektronikk]] 900f1504eb22b88ed73e2b8d4ba62839bf03a96d 6 493 2210 2016-03-02T21:56:27Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 484 2211 2150 2016-03-02T21:58:40Z Nas005 92 Nas005 uploaded a new version of [[File:1.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2213 2211 2016-03-02T22:09:12Z Nas005 92 Nas005 uploaded a new version of [[File:1.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2226 2213 2016-03-02T22:34:47Z Nas005 92 Nas005 uploaded a new version of [[File:1.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 494 2212 2016-03-02T22:06:05Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2214 2212 2016-03-02T22:09:13Z Nas005 92 Nas005 uploaded a new version of [[File:2.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2227 2214 2016-03-02T22:34:47Z Nas005 92 Nas005 uploaded a new version of [[File:2.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 495 2215 2016-03-02T22:09:14Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2228 2215 2016-03-02T22:34:48Z Nas005 92 Nas005 uploaded a new version of [[File:3.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 496 2216 2016-03-02T22:09:14Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2229 2216 2016-03-02T22:34:49Z Nas005 92 Nas005 uploaded a new version of [[File:4.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 497 2217 2016-03-02T22:09:14Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 498 2218 2016-03-02T22:09:15Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 499 2219 2016-03-02T22:09:15Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 500 2220 2016-03-02T22:09:16Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 501 2223 2016-03-02T22:16:54Z Nas005 92 Created page with "To download Vivado for free you must first create an account. By following this link Xilinx web page you will enter Xilinx download page. For this tutorial we will be using th..." wikitext text/x-wiki To download Vivado for free you must first create an account. By following this link Xilinx web page you will enter Xilinx download page. For this tutorial we will be using the 2015.4 version. To download for Windows Vivado HLx 2015.4 Web Install for Windows with SDK (EXE - 49.32 MB) For linux Vivado HLx 2015.4 Web Install for Linux with SDK (BIN - 76.98 MB) Run the installer and this will show, press next 1.png Type your user name and password and press next 2.png Agree to everything!!! Or else?!?! 3.png Choose Vivado HL WebPACK 4.png Make sure the Software Development Kit, Artix-7, Install Cable Drivers, and Acquire or Manage a License Key are all checked and click next. The DocNav file is not necessary but it allows you to • Find answers to your questions quickly through the integrated search • Manage documents on your desktop through the Download Manager • Always ensures you are reading the latest version of documentation Detailed information about using the tool and its features can be found in the Online Help Menu which you can access after installation. 5.png 6.png 7.png 8.png Choose a directory to Install you Vivado product, make sure you have adequate free space on your hard drive. The final screen summarizes your selections. Click install, and the installer will begin downloading the files it needs to install Vivado. When it is done this screen will pop up. Click ok and the license manager should open up. If not open Vivado press Help=>obtain a license key and this window will open. Choose “Get Free SDK, Vivado WebPACK” and then press Connect Now. . You will be redirected to Xilinx home page were you will need to sign in with user name and password. After clicking “sign in”, press “next” and this site will pop up Choose “Vivado Design Suite: HL WebPACK, Node-Locked License……..” and press Generate Node-Locked License. Next this window will pop up. Click next and a new window will pop up, click next again and this will show Open your E-mail and download the attached Xilinx.lic file. When you go back to the license manager this will show, press cancel. Go to Load License in the left menu. You should see this Click Copy License and upload the Xilinx.lic file and you will get this message If you now press the view license status in the left menu, you should see this You can now close the license manager and Vivado is good to go. CREATING NEW PROJECT Press create new project Press next on the first window that pops up, then you can choose were you want to store your project, click next. Choose RTL project and click next Add your VHDL file if you have one, if you don’t you can add the VGA-controller file just to make sure that everything works properly. Click next Click next Add the Nexys4_Master.xdc , this will connect all your I/O, LED, SW etc. Choose the xca100tcsg324-1 and click next and then finish. Vivado will open, now you can make your own VHDL code or you can follow instruction further if you want to use the VGA controller. If you want to make your own code you can skip the IP part and go to generate bitstream to see how you should implement your code on the FPGA. Adding IP’s, clk generator 25.2MHz and BRAM. Click IP Catalog and then Search for Clocking Wizard and enter and this will pop up, clocking option should look like this, remember to change the Component name! Change the output clock to 25.2MHz Port renaming: use names that explains your component, and click OK This should pop up, click generate Adding BRAM, search for bram and enter the Block Memory Generator and this should pop up. Remember component name Port A Options, write width = 12bits, write depth = 307200=(480*640 pixels projected on screen), then click OK and then generate as before and wait until the synthesis is done. GENERATE BITSTREAM: click generate bitstream If this pops up click yes If this message shows, just click ok, it only means that you have pins activated in your Nexys4_Master.xdc that are not in use. If later on want to change witch pins are active on your board you can configure this by entering the Nexys4_Master.xdc When completed, choose “Open Hardware Manager” and click ok At this point connect your NEXY4 board . In the left menu under “program and debug”, click open target => open new target Open new Hardware target will pop up, click next two times and this will show. Choose JTAG clock freq. 30 000 000, click next and then finish Now you can program your device, click program device and choose your FPGA Click program and your device is ready to go. 24f663b5c3afb3256acde87a76e280b622bd41c6 6 497 2230 2217 2016-03-02T22:34:50Z Nas005 92 Nas005 uploaded a new version of [[File:5.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 498 2231 2218 2016-03-02T22:34:51Z Nas005 92 Nas005 uploaded a new version of [[File:6.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 499 2232 2219 2016-03-02T22:34:52Z Nas005 92 Nas005 uploaded a new version of [[File:7.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 500 2233 2220 2016-03-02T22:34:52Z Nas005 92 Nas005 uploaded a new version of [[File:8.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 502 2234 2016-03-02T22:34:53Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 503 2235 2016-03-02T22:34:53Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 504 2236 2016-03-02T22:34:53Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 505 2237 2016-03-02T22:34:54Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 506 2238 2016-03-02T22:34:54Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 507 2239 2016-03-02T22:34:54Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 508 2240 2016-03-02T22:34:54Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 509 2241 2016-03-02T22:39:08Z Nas005 92 Created page with "To download Vivado for free you must first create an account. By following this link [http://www.xilinx.com/support/download.html/ Xilinx web page] you will enter Xilinx dow..." wikitext text/x-wiki To download Vivado for free you must first create an account. By following this link [http://www.xilinx.com/support/download.html/ Xilinx web page] you will enter Xilinx download page. For this tutorial we will be using the 2015.4 version. To download for Windows Vivado HLx 2015.4 Web Install for Windows with SDK (EXE - 49.32 MB) For linux Vivado HLx 2015.4 Web Install for Linux with SDK (BIN - 76.98 MB) Run the installer and this will show, press next [[File:1.png]] Type your user name and password and press next [[File:2.png]] Agree to everything!!! Or else?!?! [[File:3.png]] Choose Vivado HL WebPACK [[File:4.png]] Make sure the Software Development Kit, Artix-7, Install Cable Drivers, and Acquire or Manage a License Key are all checked and click next. The DocNav file is not necessary but it allows you to • Find answers to your questions quickly through the integrated search • Manage documents on your desktop through the Download Manager • Always ensures you are reading the latest version of documentation Detailed information about using the tool and its features can be found in the Online Help Menu which you can access after installation. [[File:5.png]] [[File:6.png]] [[File:7.png]] [[File:8.png]] [[File:9.png]] [[File:10.png]] [[File:11.png]] [[File:12.png]] [[File:13.png]] [[File:14.png]] [[File:15.png]] Choose a directory to Install you Vivado product, make sure you have adequate free space on your hard drive. The final screen summarizes your selections. Click install, and the installer will begin downloading the files it needs to install Vivado. When it is done this screen will pop up. Click ok and the license manager should open up. If not open Vivado press Help=>obtain a license key and this window will open. Choose “Get Free SDK, Vivado WebPACK” and then press Connect Now. . You will be redirected to Xilinx home page were you will need to sign in with user name and password. After clicking “sign in”, press “next” and this site will pop up Choose “Vivado Design Suite: HL WebPACK, Node-Locked License……..” and press Generate Node-Locked License. Next this window will pop up. Click next and a new window will pop up, click next again and this will show Open your E-mail and download the attached Xilinx.lic file. When you go back to the license manager this will show, press cancel. Go to Load License in the left menu. You should see this Click Copy License and upload the Xilinx.lic file and you will get this message If you now press the view license status in the left menu, you should see this You can now close the license manager and Vivado is good to go. 34d78c50735fec880ab0ed71a1b4588cf5c9453c 2242 2241 2016-03-02T22:48:07Z Nas005 92 wikitext text/x-wiki To download Vivado for free you must first create an account. By following this link [http://www.xilinx.com/support/download.html/ Xilinx web page] you will enter Xilinx download page. For this tutorial we will be using the 2015.4 version. To download for Windows Vivado HLx 2015.4 Web Install for Windows with SDK (EXE - 49.32 MB) For linux Vivado HLx 2015.4 Web Install for Linux with SDK (BIN - 76.98 MB) Run the installer and this will show, press next [[File:1.png]] Type your user name and password and press next [[File:2.png]] Agree to everything!!! Or else?!?! [[File:3.png]] Choose Vivado HL WebPACK [[File:4.png]] Make sure the Software Development Kit, Artix-7, Install Cable Drivers, and Acquire or Manage a License Key are all checked and click next. The DocNav file is not necessary but it allows you to * Find answers to your questions quickly through the integrated search * Manage documents on your desktop through the Download Manager * Always ensures you are reading the latest version of documentation Detailed information about using the tool and its features can be found in the Online Help Menu which you can access after installation. [[File:5.png]] Choose a directory to Install you Vivado product, make sure you have adequate free space on your hard drive. [[File:6.png]] The final screen summarizes your selections. Click install, and the installer will begin downloading the files it needs to install Vivado. When it is done this screen will pop up. [[File:7.png]] Click ok and the license manager should open up. If not open Vivado press Help=>obtain a license key and this window will open. Choose “Get Free SDK, Vivado WebPACK” and then press Connect Now. [[File:8.png]] You will be redirected to Xilinx home page were you will need to sign in with user name and password. After clicking “sign in”, press “next” and this site will pop up [[File:9.png]] Choose “Vivado Design Suite: HL WebPACK, Node-Locked License……..” and press Generate Node-Locked License. Next this window will pop up. [[File:10.png]] Click next and a new window will pop up, click next again and this will show [[File:11.png]] Open your E-mail and download the attached Xilinx.lic file. When you go back to the license manager this will show, press cancel. [[File:12.png]] Go to Load License in the left menu. You should see this [[File:13.png]] Click Copy License and upload the Xilinx.lic file and you will get this message [[File:14.png]] If you now press the view license status in the left menu, you should see this [[File:15.png]] You can now close the license manager and Vivado is good to go. bcc2de3f277cbb4bd5cc683b81e96f285bba0d92 0 510 2243 2016-03-02T22:51:24Z Nas005 92 Created page with "library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity Vga is Port ( clk_i : in STD_LOGIC; sw_i :..." wikitext text/x-wiki library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity Vga is Port ( clk_i : in STD_LOGIC; sw_i : in STD_LOGIC_VECTOR (15 downto 0); -- (11 downto 8) is RED, (7 downto 4) is GREEN, (3 downto 0) is BLUE -- Writing directly to RAM and from RAM to VGA interface. -- Writing when sw_i(15) is high -- VGA Output Signals vga_hs_o : out STD_LOGIC; -- Horizontal sync puls to VGA interface vga_vs_o : out STD_LOGIC; -- Vertical sync puls to VGA interface vga_red_o : out STD_LOGIC_VECTOR (3 downto 0); -- Red to VGA interface vga_green_o : out STD_LOGIC_VECTOR (3 downto 0); -- Green to VGA interface vga_blue_o : out STD_LOGIC_VECTOR (3 downto 0) -- Blue to VGA interface ); end Vga; architecture Behavioral of Vga is ------------------------------------------------------------------------- -- Component Declarations ------------------------------------------------------------------------- -- 25.2MHz Clock COMPONENT clk_wiz_25_2MHz PORT ( clk_in_100MHz: in STD_LOGIC; clk_out_25_2: out STD_LOGIC; reset : in STD_LOGIC; locked : out STD_LOGIC ); END COMPONENT; -- Ram block for pixels COMPONENT PIX_RAM PORT ( clka : IN STD_LOGIC; ena : IN STD_LOGIC; wea : IN STD_LOGIC_VECTOR(0 DOWNTO 0); addra : IN STD_LOGIC_VECTOR(18 DOWNTO 0); dina : IN STD_LOGIC_VECTOR(11 DOWNTO 0); douta : OUT STD_LOGIC_VECTOR(11 DOWNTO 0) ); END COMPONENT; ------------------------------------------------------------- -- Constants for VGA Resolutions ------------------------------------------------------------- ------640x480 60Hz------- constant WIDTH : natural := 640; constant HEIGHT : natural := 480; constant H_FP : natural := 16; --H front porch width (pixels) constant H_PW : natural := 96; --H sync pulse width (pixels) constant H_TOT : natural := 800; --H total period (pixels) constant V_FP : natural := 10; --V front porch width (lines) constant V_PW : natural := 2; --V sync pulse width (lines) constant V_TOT : natural := 525; --V total period (lines) ------------------------------------------------------------------------- -- VGA signals: Counters, Sync, Red, Gree, Blue ------------------------------------------------------------------------- -- Activates the screen when it is in the frame area signal SCREEN_ON : std_logic; -- Horizontal and Vertical counters signal h_count : std_logic_vector(11 downto 0) := (others =>'0'); signal v_count : std_logic_vector(11 downto 0) := (others =>'0'); -- signal for the VGA interface signal vga_red : std_logic_vector(3 downto 0); signal vga_blue : std_logic_vector(3 downto 0); signal vga_green : std_logic_vector(3 downto 0); ------------------------------------------------------------------------- -- CLOCK signals ------------------------------------------------------------------------- signal pxl_clk: std_logic; -- pxl_clk is 25.2MHz signal reset: std_logic := '0'; ------------------------------------------------------------------------- -- RAM signals ------------------------------------------------------------------------- signal data_out : std_logic_vector(11 downto 0) := (others =>'0'); signal data_inn : std_logic_vector(11 downto 0) := (others =>'0'); signal address : std_logic_vector(18 downto 0) := (others =>'0'); signal write : std_logic_vector(0 downto 0) ; begin --------------------------- -- PORT MAPS --------------------------- -- PIXELGENERATOR - pxl_clk=25.2MHz PIXELGENERATOR : clk_wiz_25_2MHz PORT MAP (--clock inn clk_in_100MHz => clk_i, --clock out clk_out_25_2 => pxl_clk, --reset active high reset => reset, --status and controll signals locked => open ); -- RAM RAM : PIX_RAM PORT MAP ( clka => clk_i, ena => '1', wea => write, addra => address, dina => data_inn, douta => data_out ); ----------------------------------------------------------------- -- Generate Horizontal, Vertical counters and the Sync signals ----------------------------------------------------------------- -- Horizontal counter process (pxl_clk) begin if (rising_edge(pxl_clk)) then if (h_count = (H_TOT - 1)) then h_count <= (others =>'0'); else h_count <= h_count + 1; end if; end if; end process; -- Vertical counter process (pxl_clk) begin if (rising_edge(pxl_clk)) then if ((h_count = (H_TOT - 1)) and (v_count = (V_TOT - 1))) then v_count <= (others =>'0'); elsif (h_count = (H_TOT - 1)) then v_count <= v_count + 1; end if; end if; end process; -- Horizontal sync process (pxl_clk) begin if (rising_edge(pxl_clk)) then if (h_count >= (H_FP + WIDTH - 1)) and (h_count < (H_FP + WIDTH + H_PW - 1)) then vga_hs_o <= '1'; else vga_hs_o <= '0'; end if; end if; end process; -- Vertical sync process (pxl_clk) begin if (rising_edge(pxl_clk)) then if (v_count >= (V_FP + HEIGHT - 1)) and (v_count < (V_FP + HEIGHT + V_PW - 1)) then vga_vs_o <= '1'; else vga_vs_o <= '0'; end if; end if; end process; ------------------------------------------------------- -- RAM interface ------------------------------------------------------- -- Synchronizing reading and writing of adresses with the VGA interface process (pxl_clk) begin if (rising_edge(pxl_clk)) then if h_count < WIDTH and v_count < HEIGHT then address <= address + 1; else address <= (others =>'0'); end if; end if; end process; -------------------- -- SCREEN ON -------------------- -- screening signal SCREEN_ON <= '1' when h_count < WIDTH and v_count < HEIGHT else '0'; ------------------------------------------------------------ -- Turn Off VGA RBG Signals if outside of the active screen -- Make a 4-bit AND logic with the R, G and B signals ------------------------------------------------------------ vga_red_o <= (SCREEN_ON & SCREEN_ON & SCREEN_ON & SCREEN_ON) and vga_red; vga_green_o <= (SCREEN_ON & SCREEN_ON & SCREEN_ON & SCREEN_ON) and vga_green; vga_blue_o <= (SCREEN_ON & SCREEN_ON & SCREEN_ON & SCREEN_ON) and vga_blue; -------------------- -- Rerouting signals -------------------- vga_red <= data_out(11 downto 8); vga_green <= data_out(7 downto 4); vga_blue <= data_out(3 downto 0); data_inn <= sw_i(11 downto 0); -- (11 downto 8) is RED, (7 downto 4) is GREEN, (3 downto 0) is BLUE write <= sw_i(15 downto 15); -- Activ high when writing to BRAM end Behavioral; 60f6f9b053c84eba33c67d388e9429053c91ed83 2245 2243 2016-03-02T22:57:24Z Nas005 92 Replaced content with "[[:File:vga.txt]]" wikitext text/x-wiki [[:File:vga.txt]] 544742a84fc91c56923a0c855aff6831ea175bc5 6 511 2244 2016-03-02T22:56:46Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 512 2246 2016-03-02T23:04:26Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 513 2247 2016-03-02T23:04:36Z Nas005 92 Created page with "[[:File:Nexys4_Master.txt]]" wikitext text/x-wiki [[:File:Nexys4_Master.txt]] e7fd657d6f3cbde0e24e18b91cefca086fec299a 6 514 2248 2016-03-02T23:06:59Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 515 2249 2016-03-02T23:06:59Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 516 2250 2016-03-02T23:07:00Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 517 2251 2016-03-02T23:07:00Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 518 2252 2016-03-02T23:07:00Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 519 2253 2016-03-02T23:07:01Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 520 2254 2016-03-02T23:07:02Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 521 2255 2016-03-02T23:07:02Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 522 2256 2016-03-02T23:07:02Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 523 2257 2016-03-02T23:07:02Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 524 2258 2016-03-02T23:07:03Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 525 2259 2016-03-02T23:07:03Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 526 2260 2016-03-02T23:07:03Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 527 2261 2016-03-02T23:07:03Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 528 2262 2016-03-02T23:07:04Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 529 2263 2016-03-02T23:07:04Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 530 2264 2016-03-02T23:07:04Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 531 2265 2016-03-02T23:07:04Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 532 2266 2016-03-02T23:07:05Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 533 2267 2016-03-02T23:07:05Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 534 2268 2016-03-02T23:07:05Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 535 2269 2016-03-02T23:07:05Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 536 2270 2016-03-02T23:07:06Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 537 2271 2016-03-02T23:07:06Z Nas005 92 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 538 2272 2016-03-02T23:21:55Z Nas005 92 Created page with "If you want to use the vga controller remember to * copy-paste the vga.txt file and save it as vga.vhd * copy-paste the Nexys4_Master.txt file and save it as Nexys4_Master.x..." wikitext text/x-wiki If you want to use the vga controller remember to * copy-paste the vga.txt file and save it as vga.vhd * copy-paste the Nexys4_Master.txt file and save it as Nexys4_Master.xdc CREATING NEW PROJECT Press create new project [[File:16.png|400px]] Press next on the first window that pops up, then you can choose were you want to store your project, click next. [[File:17.png|400px]] Choose RTL project and click next [[File:18.png|400px]] Add your VHDL file if you have one, if you don’t you can add the VGA-controller file just to make sure that everything works properly. Click next [[File:19.png|400px]] Click next [[File:20.png|400px]] Add the Nexys4_Master.xdc , this will connect all your I/O, LED, SW etc. [[File:21.png|400px]] Choose the xca100tcsg324-1 and click next and then finish. [[File:22.png|400px]] Vivado will open, now you can make your own VHDL code or you can follow instruction further if you want to use the VGA controller. If you want to make your own code you can skip the IP part and go to generate bitstream to see how you should implement your code on the FPGA. [[File:23.png|400px]] Adding IP’s, clk generator 25.2MHz and BRAM. Click IP Catalog and then [[File:24.png|400px]] Search for Clocking Wizard and enter and this will pop up, clocking option should look like this, remember to change the Component name! [[File:25.png|400px]] Change the output clock to 25.2MHz [[File:26.png|400px]] Port renaming: use names that explains your component, and click OK [[File:27.png|400px]] This should pop up, click generate [[File:28.png|400px]] Adding BRAM, search for bram and enter the Block Memory Generator and this should pop up. Remember component name [[File:29.png|400px]] Port A Options, write width = 12bits, write depth = 307200=(480*640 pixels projected on screen), then click OK and then generate as before and wait until the synthesis is done. [[File:30.png|400px]] GENERATE BITSTREAM: click generate bitstream [[File:31.png|400px]] If this pops up click yes [[File:32.png|400px]] If this message shows, just click ok, it only means that you have pins activated in your Nexys4_Master.xdc that are not in use. [[File:33.png|400px]] If later on want to change witch pins are active on your board you can configure this by entering the Nexys4_Master.xdc [[File:34.png|400px]] When completed, choose “Open Hardware Manager” and click ok [[File:35.png|400px]] At this point connect your NEXY4 board . In the left menu under “program and debug”, click open target => open new target [[File:36.png|400px]] Open new Hardware target will pop up, click next two times and this will show. Choose JTAG clock freq. 30 000 000, click next and then finish [[File:37.png|400px]] Now you can program your device, click program device and choose your FPGA [[File:38.png|400px]] Click program and your device is ready to go. [[File:39.png|400px]] ceed3e5aee0cfc1d9bb6ae5d06de887f3742fe0e 2273 2272 2016-03-02T23:33:10Z Nas005 92 wikitext text/x-wiki If you want to use the vga controller remember to * copy-paste the vga.txt file and save it as vga.vhd * copy-paste the Nexys4_Master.txt file and save it as Nexys4_Master.xdc The vga controller is using a BRAM block to store pixel values. Each pixel has 12-bits and number of pixels projected to the screen is 480x640=307200 * sw_i(15) -- active high, write enable * sw_i(11 downto 0) -- 12-bits for colour changing the screen CREATING NEW PROJECT Press create new project [[File:16.png|400px]] Press next on the first window that pops up, then you can choose were you want to store your project, click next. [[File:17.png|400px]] Choose RTL project and click next [[File:18.png|400px]] Add your VHDL file if you have one, if you don’t you can add the VGA-controller file just to make sure that everything works properly. Click next [[File:19.png|400px]] Click next [[File:20.png|400px]] Add the Nexys4_Master.xdc , this will connect all your I/O, LED, SW etc. [[File:21.png|400px]] Choose the xca100tcsg324-1 and click next and then finish. [[File:22.png|400px]] Vivado will open, now you can make your own VHDL code or you can follow instruction further if you want to use the VGA controller. If you want to make your own code you can skip the IP part and go to generate bitstream to see how you should implement your code on the FPGA. [[File:23.png|400px]] Adding IP’s, clk generator 25.2MHz and BRAM. Click IP Catalog and then [[File:24.png|400px]] Search for Clocking Wizard and enter and this will pop up, clocking option should look like this, remember to change the Component name! [[File:25.png|400px]] Change the output clock to 25.2MHz [[File:26.png|400px]] Port renaming: use names that explains your component, and click OK [[File:27.png|400px]] This should pop up, click generate [[File:28.png|400px]] Adding BRAM, search for bram and enter the Block Memory Generator and this should pop up. Remember component name [[File:29.png|400px]] Port A Options, write width = 12bits, write depth = 307200=(480*640 pixels projected on screen), then click OK and then generate as before and wait until the synthesis is done. [[File:30.png|400px]] GENERATE BITSTREAM: click generate bitstream [[File:31.png|400px]] If this pops up click yes [[File:32.png|400px]] If this message shows, just click ok, it only means that you have pins activated in your Nexys4_Master.xdc that are not in use. [[File:33.png|400px]] If later on want to change witch pins are active on your board you can configure this by entering the Nexys4_Master.xdc [[File:34.png|400px]] When completed, choose “Open Hardware Manager” and click ok [[File:35.png|400px]] At this point connect your NEXY4 board . In the left menu under “program and debug”, click open target => open new target [[File:36.png|400px]] Open new Hardware target will pop up, click next two times and this will show. Choose JTAG clock freq. 30 000 000, click next and then finish [[File:37.png|400px]] Now you can program your device, click program device and choose your FPGA [[File:38.png|400px]] Click program and your device is ready to go. [[File:39.png|400px]] 6a03f80a7c342fc3a0c03d2c8e78b2e6dea74148 0 33 2274 2097 2016-03-24T11:21:00Z Ogr043 86 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cyclonev /prog/altera/vhdl_libs/cyclonev vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] [[Synthese av VHDL - Oppdatert]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] [http://www.ashenden.com.au/ Ashenden Designs] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] [http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [http://bitvis.no/products/bitvis-utility-library/ Bitvis utility library] [[Category:Mikroelektronikk]] 824c2df0bebd952d059dd64795d2539d35e58ce5 0 539 2275 2016-03-24T12:26:03Z Ogr043 86 Created page with "===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter..." wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneV-chip. Vi valgte 5CSEMA5F31C6. Det er chipen på Terasic DE1-SoC. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. ==Modelsim== ==Simulering med timing== ==Konklusjon== ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> 53013bcc0dfb871dc27f5e1b7ecc7a1e3d2bb3e3 2276 2275 2016-03-24T12:56:28Z Ogr043 86 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneIV-chip. Vi valgte EP4CE115F29. Det er chipen på Terasic DE2-115. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. I simulation/modelsim/ finner vi nå add_sub_alu.vho og add_sub_alu_vhd.sdo. Vho-filen(VHDL Output File) er filen som inneholder nå det opprinnelige designet, men også mange nye moduler med cycloneive-prefix. Disse entitetene beskriver ressurser på den fysiske FPGA-chipen. Sdo-filen(Standard Delay Format Output File) inneholder detaljer om delay fra hver modul på chippen. ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila for designet add_sub_alu.vhd og testbenken alu_tb.vhd. Så legg vi til fila som Quartus generte i prosjektdir til simulation/modelsim/add_sub_alu.vho. Den Quartus-genererte filen vil ha samme entitetsnavn som den opprinnelige, og vil derfor ikke kunne simuleres samtid. Vi endrer derfor den genererte filen til å ha entiteten 'add_sub_alu_synth' og architecturen 'structure' (i vårt tilfelle endret den seg til structure automatisk). Vi kan nå kompilere filene våre: ==Simulering med timing== ==Konklusjon== ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> 63e29976b99582bfe0c25ec30f6a2bbb85451ff9 2277 2276 2016-03-24T13:16:24Z Ogr043 86 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneIV-chip. Vi valgte EP4CE115F29. Det er chipen på Terasic DE2-115. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. I simulation/modelsim/ finner vi nå add_sub_alu.vho og add_sub_alu_vhd.sdo. Vho-filen(VHDL Output File) er filen som inneholder nå det opprinnelige designet, men også mange nye moduler med cycloneive-prefix. Disse entitetene beskriver ressurser på den fysiske FPGA-chipen. Sdo-filen(Standard Delay Format Output File) inneholder detaljer om delay fra hver modul på chippen. ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila for designet add_sub_alu.vhd og testbenken alu_tb.vhd. Så legg vi til fila som Quartus generte i prosjektdir til simulation/modelsim/add_sub_alu.vho. Den Quartus-genererte filen vil ha samme entitetsnavn som den opprinnelige, og vil derfor ikke kunne simuleres samtid. Vi endrer derfor den genererte filen til å ha entiteten 'add_sub_alu_synth' og architecturen 'structure' (i vårt tilfelle endret den seg til structure automatisk). Vi kan nå kompilere filene våre og deretter simulere testbenken. I testbenken vår ser vi at vi har kalt den syntiserte entiteten alu_synt. Dette skal vi bruke nå. Velg Start Simulation - deretter work og alu_tb. Se så på SDF-fanen. Legg til add_sub_alu_vhd.sdo generert av Quartus tidligere. Under apply to region må du skrive: /alu_tb/alu_synt Dette er altså området vi ønsker at sdo-filen skal gi informasjon om. Trykk så OK. add wave * ==Simulering med timing== ==Konklusjon== ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> 0cb18c15d2a92f8950402dea6e0aaf58fadd6079 2278 2277 2016-03-26T16:06:07Z Ogr043 86 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneIV-chip. Vi valgte EP4CE115F29. Det er chipen på Terasic DE2-115. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. I simulation/modelsim/ finner vi nå add_sub_alu.vho og add_sub_alu_vhd.sdo. Vho-filen(VHDL Output File) er filen som inneholder nå det opprinnelige designet, men også mange nye moduler med cycloneive-prefix. Disse entitetene beskriver ressurser på den fysiske FPGA-chipen. Sdo-filen(Standard Delay Format Output File) inneholder detaljer om delay fra hver modul på chippen. ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila for designet add_sub_alu.vhd og testbenken alu_tb.vhd. Så legg vi til fila som Quartus generte i prosjektdir til simulation/modelsim/add_sub_alu.vho. Den Quartus-genererte filen vil ha samme entitetsnavn som den opprinnelige, og vil derfor ikke kunne simuleres samtid. Vi endrer derfor den genererte filen til å ha entiteten 'add_sub_alu_synth' og architecturen 'structure' (i vårt tilfelle endret den seg til structure automatisk). Vi kan nå kompilere filene våre og deretter simulere testbenken. I testbenken vår ser vi at vi har kalt den syntiserte entiteten alu_synt. Dette skal vi bruke nå. ==Simulering med timing== Velg Start Simulation - deretter work og alu_tb. Se så på SDF-fanen. Legg til add_sub_alu_vhd.sdo generert av Quartus tidligere. Under apply to region må du skrive: /alu_tb/alu_synt Dette er altså området vi ønsker at sdo-filen skal gi informasjon om. Trykk så OK. add wave * run -all Vi kan nå sammenligne utsignalene for den usyntiserte og den syntiserte ALU-komponenten. ==Konklusjon== Vi ser at vi får masse feil før 50 ns. Dette skyldes at den opprinnelige komponenten ikke har definerte signaler før de første klokkeflankene, mens den syntiserte komponenten ikke kan ha udefinerte signaler. Senere får vi feil når signalene skifter. Dette skyldes at den syntiserte komponenten bruker lengre tid på å sende ut riktig signal, og vil også glitche mellom verdier før den stabiliserer seg på riktig verdi. ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> c2a4141398847fe2dab9e58d4f54c815875748e4 2279 2278 2016-03-26T16:41:11Z Ogr043 86 wikitext text/x-wiki Obs! Fra Quartus Prime Handbook: Gate-level timing simulation of an entire design can be slow and should be avoided. Gate-level timing simulation is supported only for the Stratix IV and Cyclone IV device families. Use TimeQuest static timing analysis rather than gate-level timing simulation. ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneIV-chip. Vi valgte EP4CE115F29. Det er chipen på Terasic DE2-115. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. I simulation/modelsim/ finner vi nå add_sub_alu.vho og add_sub_alu_vhd.sdo. Vho-filen(VHDL Output File) er filen som inneholder nå det opprinnelige designet, men også mange nye moduler med cycloneive-prefix. Disse entitetene beskriver ressurser på den fysiske FPGA-chipen. Sdo-filen(Standard Delay Format Output File) inneholder detaljer om delay fra hver modul på chippen. ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila for designet add_sub_alu.vhd og testbenken alu_tb.vhd. Så legg vi til fila som Quartus generte i prosjektdir til simulation/modelsim/add_sub_alu.vho. Den Quartus-genererte filen vil ha samme entitetsnavn som den opprinnelige, og vil derfor ikke kunne simuleres samtid. Vi endrer derfor den genererte filen til å ha entiteten 'add_sub_alu_synth' og architecturen 'structure' (i vårt tilfelle endret den seg til structure automatisk). Vi kan nå kompilere filene våre og deretter simulere testbenken. I testbenken vår ser vi at vi har kalt den syntiserte entiteten alu_synt. Dette skal vi bruke nå. ==Simulering med timing== Velg Start Simulation - deretter work og alu_tb. Se så på SDF-fanen. Legg til add_sub_alu_vhd.sdo generert av Quartus tidligere. Under apply to region må du skrive: /alu_tb/alu_synt Dette er altså området vi ønsker at sdo-filen skal gi informasjon om. Trykk så OK. add wave * run -all Vi kan nå sammenligne utsignalene for den usyntiserte og den syntiserte ALU-komponenten. ==Konklusjon== Vi ser at vi får masse feil før 50 ns. Dette skyldes at den opprinnelige komponenten ikke har definerte signaler før de første klokkeflankene, mens den syntiserte komponenten ikke kan ha udefinerte signaler. Senere får vi feil når signalene skifter. Dette skyldes at den syntiserte komponenten bruker lengre tid på å sende ut riktig signal, og vil også glitche mellom verdier før den stabiliserer seg på riktig verdi. ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> 685ce772065d5962949c8b330ce145bc848a13e7 0 539 2280 2279 2016-03-26T16:41:23Z Ogr043 86 wikitext text/x-wiki Obs! Fra Quartus Prime Handbook: Gate-level timing simulation of an entire design can be slow and should be avoided. Gate-level timing simulation is supported only for the Stratix IV and Cyclone IV device families. Use TimeQuest static timing analysis rather than gate-level timing simulation. ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneIV-chip. Vi valgte EP4CE115F29. Det er chipen på Terasic DE2-115. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. I simulation/modelsim/ finner vi nå add_sub_alu.vho og add_sub_alu_vhd.sdo. Vho-filen(VHDL Output File) er filen som inneholder nå det opprinnelige designet, men også mange nye moduler med cycloneive-prefix. Disse entitetene beskriver ressurser på den fysiske FPGA-chipen. Sdo-filen(Standard Delay Format Output File) inneholder detaljer om delay fra hver modul på chippen. ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila for designet add_sub_alu.vhd og testbenken alu_tb.vhd. Så legg vi til fila som Quartus generte i prosjektdir til simulation/modelsim/add_sub_alu.vho. Den Quartus-genererte filen vil ha samme entitetsnavn som den opprinnelige, og vil derfor ikke kunne simuleres samtid. Vi endrer derfor den genererte filen til å ha entiteten 'add_sub_alu_synth' og architecturen 'structure' (i vårt tilfelle endret den seg til structure automatisk). Vi kan nå kompilere filene våre og deretter simulere testbenken. I testbenken vår ser vi at vi har kalt den syntiserte entiteten alu_synt. Dette skal vi bruke nå. ==Simulering med timing== Velg Start Simulation - deretter work og alu_tb. Se så på SDF-fanen. Legg til add_sub_alu_vhd.sdo generert av Quartus tidligere. Under apply to region må du skrive: /alu_tb/alu_synt Dette er altså området vi ønsker at sdo-filen skal gi informasjon om. Trykk så OK. add wave * run -all Vi kan nå sammenligne utsignalene for den usyntiserte og den syntiserte ALU-komponenten. ==Konklusjon== Vi ser at vi får masse feil før 50 ns. Dette skyldes at den opprinnelige komponenten ikke har definerte signaler før de første klokkeflankene, mens den syntiserte komponenten ikke kan ha udefinerte signaler. Senere får vi feil når signalene skifter. Dette skyldes at den syntiserte komponenten bruker lengre tid på å sende ut riktig signal, og vil også glitche mellom verdier før den stabiliserer seg på riktig verdi. ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> e116ee1ce8c632cf333f8bee4a0fb3e51b65667f 0 38 2281 2125 2016-04-12T08:06:54Z Ogr043 86 wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Get schematic ready for layout]] [[Layout XL and IHP SG13S]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[Category:Mikroelektronikk]] a5b4fc32412e11873a461a887882d19a8e256df2 2283 2281 2016-04-12T09:15:00Z Ogr043 86 wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[Category:Mikroelektronikk]] b7141a7db73cdc5d0a53cc51ad945d4f4ce3dbc0 2307 2283 2016-05-06T17:10:55Z Mer020 87 /* Helpful stuff */ wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] 363f9e5f66a2697461289d792300bf9b6ec9540f 6 540 2282 2016-04-12T09:01:38Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 541 2284 2016-04-12T09:17:30Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 542 2285 2016-04-12T09:31:51Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 543 2286 2016-04-12T09:31:51Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 544 2287 2016-04-12T09:43:10Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 545 2288 2016-04-12T09:43:10Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 546 2289 2016-04-12T09:43:36Z Ogr043 86 Created page with "= Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand..." wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] 3935448c905fe199e24683d42789990202eef32e 2294 2289 2016-04-12T10:14:43Z Ogr043 86 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|100px]] [[File:partial2.png|100px]] 6341655e512e962f6bb18a031ed3bc5bacb45f89 2295 2294 2016-04-12T10:15:03Z Ogr043 86 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] 6eabb666ae64a6e3725e10dc5625a703ac424f98 2298 2295 2016-04-12T10:21:16Z Ogr043 86 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] a81bf19a6d0d3e09fda97a66f96a40fe3d7a0eda 2301 2298 2016-04-12T11:05:14Z Ogr043 86 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Rule Set: Fill and Density. = LVS = Run LVS by pressing Assura -> Run LVS. ca07eb3dbe2268df50fc5ccd11828834d9aa32f2 2302 2301 2016-04-12T11:46:30Z Ogr043 86 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = Run LVS by pressing Assura -> Run LVS. e9cce627b5d1cf045f870b757e55d418c660f595 6 547 2290 2016-04-12T09:59:58Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 548 2291 2016-04-12T10:06:18Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 549 2292 2016-04-12T10:14:21Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 550 2293 2016-04-12T10:14:21Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 551 2296 2016-04-12T10:20:22Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 552 2297 2016-04-12T10:20:22Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 553 2299 2016-04-12T10:43:28Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 554 2300 2016-04-12T10:47:15Z Ogr043 86 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 3 2303 2050 2016-04-21T07:10:06Z Are033 82 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga2.bit busybox_fpga2.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 7bbdb75b30aae9b6f009af620fe3bffe8c1fba5f 2304 2303 2016-04-22T09:12:57Z Are033 82 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 96fb69318d614948cea4f0c94a1f366e837400b3 2309 2304 2016-05-09T09:43:39Z Are033 82 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): I counted D: Down, U: Up, L: Left. 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 1d5b7d553cada6ecaaf33731777c29e01784cdab 2310 2309 2016-05-09T11:00:12Z Are033 82 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left. 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] bbcad3449889e82e06047070d11bd97eadbe7b39 2311 2310 2016-05-09T12:41:10Z Are033 82 /* Logical address mapping to physical connectors on busy-box */ wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left. [[File:Bb mapping.jpg|framed|center|bb_mapping.jpg]] 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] a8a21218c8ed69bda0afe2f847f9f072d90a6f1c 2313 2311 2016-05-09T12:45:18Z Are033 82 /* Logical address mapping to physical connectors on busy-box */ wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left. 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] ae60d53c533556ed0a5d422ec1b73d2617dcd406 2314 2313 2016-05-09T12:49:30Z Are033 82 /* Logical address mapping to physical connectors on busy-box */ wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left. [[File:Bb_mapping.jpg]] 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] a95e66132b7b5284a116b30d0f2ea1cbe3a107b4 2321 2314 2016-05-19T18:02:31Z Are033 82 /* Using Trigger Receiver Module v 1.9 (30.06.2015) */ wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting rom. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Register map is set according to RCU2:'''Old trigger address map is not valid'''. New address map is found here[[:File:TTCrx_receiver_v2.0.2.pdf]]. * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left. [[File:Bb_mapping.jpg]] 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 41c4b81c7b6a7ebc72dc40c3b9b96acae0a67f2a 2326 2321 2016-06-07T07:05:13Z Are033 82 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting room. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[http://web.ift.uib.no/kjekscgi-bin/viewcvs.cgi/vhdlcvs/trigger_receiver/ Trigger Receiver CVS] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. Alternatively fpga2 can be prgrammed with 'dummy.bit'. ==== Compiled BusyBox Firmware Versions ==== =====Revision 31===== ;:* Using Trigger Receiver Module v.1.3 ;:* Now handles orphan L2 Accept triggers by looking at the payload bit in the event info. ;:;Download ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga1.bit busybox_fpga1.bit] ;::*[http://web.ift.uib.no/firmware/BusyBox/revision31/busybox_fpga2.bit busybox_fpga2.bit] ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Register map is set according to RCU2:'''Old trigger address map is not valid'''. New address map is found here[[:File:TTCrx_receiver_v2.0.2.pdf]]. * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left. [[File:Bb_mapping.jpg]] 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] =====Revision 66===== ======Using Trigger Receiver Module v 2.1 (06.06.2016)====== [https://twiki.cern.ch/twiki/bin/viewauth/ALICE/TPC_RCU2_TTC_Module Click for Trigger Receiver updates] *This release only updates the trigger receiver module and firmware is tested to receive all valid trigger sequences. *Please perform a complete integration (DAQ+RCU+BusyBox) test in lab before using it at experiment. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision66/busybox_fpga1.bit busybox_fpga1.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] bf0c726b0e207d66d671149811103c0863647c84 2327 2326 2016-06-07T11:35:47Z Nfyku 4 Updated to version 66 wikitext text/x-wiki ==Contact info== The Busy Box Hardware and Firmware is developed at the Department of Physics and Technology, University of Bergen. For questions and enquiries please contact [http://www.uib.no/personer/Attiq.Rehman Attiq Rehman] and [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland]. == Overview == [[Image:Block_busybox.jpg‎|thumb|791px|center|Block diagram BusyBox]] <br><br> ALICE is one of four large detectors situated at the collision points in the Large Hadron Collider (LHC) at CERN. The BusyBox is used by four of ALICE’s sub-detectors: Time Projection Chamber (TPC), Photon Spectrometer (PHOS), Forward Multiplicity Detector (FMD) and Electromagnetic Calorimeter (EMCal) Triggers initiate data readout from ALICE’s sub-detectors and are received by the DCS board via an optical cable interface. The triggers and associated data are routed from the TTCrx ASIC on the DCS board to the BusyBox FPGA(s). Here, the L1a and Serial B line raw data is decoded by the Trigger Receiver firmware module. Every time a trigger sequence starts the Fee starts buffering data, i.e. a buffer in the Fee is used. A valid trigger sequence ends with an L2a trigger and the event data along with the event ID is sent to the D-RORCs. The purpose of BusyBox is to let the Central Trigger Processor (CTP) know when the Fee’s buffers are full by asserting a busy signal which prevents further issuing of triggers. The BusyBox and D-RORCs receives a unique event ID from the Fee after an event. After a valid trigger sequence ends the BusyBox will ask the D-RORCs if they have received the same event ID as the BusyBox did. If they do not reply with the same ID it means data has not been shipped from the Fee to the D-RORC, hence, the buffer in the Fee still holds event data. The Fee buffers can hold 4 or 8 events and the BusyBox keeps track of free buffers. The busy is asserted if the buffers are full. Interaction with the BusyBox is done through the DCS board, either via Ethernet or UART. The BusyBoxes are located in the DAQ counting room. == BusyBox Hardware overview == The BusyBox uses the Virtex-4 LX-40 FPGAs with the ff1148 package from Xilinx. Each device has 640 user programmable I/O pins that support LVDS 2.5 standard used to communicate with the D-RORCs. The Virtex-4 can run on clock speeds up to 500 MHz, store 18 kbits in 96 BRAM modules and has DCM to provide flexible clocking and synchronization. == BusyBox Hardware tests at UiB == In one of our labs at UiB we have a setup for testing new BusyBox firmware in hardware before releasing it. The setup features a full readout chain for one channel of the ALICE TPC.<br> ===== Components in LAB setup : ===== * Local Trigger Crate (LTU) * Readout Control Unit (RCU) with Front End Cards (FEC) * Local Data Concentrator (LDC) with 3 DAQ ReadOut Receiver Cards (DRORC) and date software. * BusyBox with 2 FPGAs but only 1U rack. See Also [[How to run the RCU - DRORC - Busybox setup]] == BusyBox Firmware == ====Busy Box Registers==== See [[Busy_Box_and_related/BusyBox Registers|BusyBox Registers]] for latest updated information on firmware registers. ==== Source Code Repositories ==== *[http://subversion.ift.uib.no/svn/busybox_firmware BusyBox SVN repository] *[https://gitlab.cern.ch/alice-tpc-rcu2/GIT-ALICE-RCU2/tree/ttc/RCU2/firmware/SF2/src/modules/ttcrx Trigger Receiver GIT repos] ====BusyBox FPGAs==== There are two versions of the BusyBox. One with two FPGAs and the other with only one FPGA. If only one FPGA is present it should be programmed with 'busybox_fpga1_solo.bit'. If two FPGAs are present then use 'busybox_fpga1.bit' and 'busybox_fpga2.bit'. From version 65 only one FPGA is in use. Make sure to program the second FPGA with 'fpga2_dummy.bit', else the FPGAs can not be accessed from the DCS card. ==== Compiled BusyBox Firmware Versions ==== ======Versioning====== The busybox version number is now the same as the revision number of the source in SVN it was generated from. This should make it possible to get the original source files for any programming file. A register for the version number exists in the ctrl_regs module. =====Revision 41===== ======Non functional FW changes====== # Signal names used globally in the design have been renamed: clocka => clk200, clockb => clk40, areset => rst40 /rst200 # All processes in all VHDL files used in the design, except for the trigger receiver module, have been updated to implement a synchronous reset. # Since a stable clock is required for to perform a proper synchronous reset, a new module that implements reset logic has been added to the design in busylogic_top module. The reset logic will assert reset for as long as the DCM has not locked on the incoming clock. The reset will be released synchronously about 10 cycles after the DCM has asserted its locked signal. # Since the actual clock of the LHC is 40.08 MHz and not the nominal 40 MHz the constraints for the implementation tools has been set 41 MHz. (85 degrees celsius, 41 MHz, 1.14 V) ======Event verification module (event_validator_top)====== This module has been modified so that the event ID queue now also contains the event info and event errors in addition to the event ID. The event info and event errors for the newest and current events are made available as registers. This extra info about the trigger sequence can be helpful when debugging. The event info contains the payload bit which is forwarded to the busy_controller. It is used in the process of calculating used MEBs. ======Serial decoder====== The serial decoder has been changed to reduce the resource usage. This module is replicated many times in the design so any improvement is significant. The old architecture used a shift register long enough to hold all bit-samples for one data frame (about 100 samples). The frame was captured in one go when a valid capture condition was found in the samples. The new architecture uses shorter shift register (about 10 samples) and only looks at a few samples at a time. Once the start condition is found it will capture the bits of the frame sequentially, bit by bit. The new architecture of this module has led to great improvements in resource usage. BusyBox firmware with 96 channels used to occupy approximately 96% of the FPGA. This number has been reduced to approximately 66%. Reduced resource usage makes it easier for the implementation tools to generate the programming file and it should also reduce the TDP of the device under operation. ======DCS arbiter and address decoder====== The architecture of this module has been updated to make it more readable and to register inputs such as address and data from the DCS bus master. ======Registers====== Extra registers has been added: #Number of implemented channels. This number is actually the same as the generic g_num_channels. #Current Trigger Event Info #Current Trigger Event Error #Newest Trigger Event Info #Newest Trigger Event Error ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision41/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 49===== ======Free Buffer counting scheme====== The buffer counter is now incremented on L2A only, and decremented as before on Valid Event signal (meaning that all DRORCs have received the current event). In previous versions the buffer counter was incremented on L1A and decremented on L2R, time-outs and valid events. ======Trigger burst interlock====== A new feature has been added. The purpose is to prevent long bursts of trigger. A maximum number of triggers in a burst can be defined in the burst size register. A counter ("leaky bucket") counts up until a the maximum value is reached for every L0 trigger received. It counts down on pulses from a pulse generator until minimum (0). The interval of these "leak-pulses" is programmable from 0 to 200 ms in 10 us steps. We are busy when the "leaky bucket" is full. This feature can be disabled by setting the burst size to 0 (default value). Two new registers are added: #Burst Size (address 0x2017) #Burst Leak Time (address (0x2018) A new status bit has been added to the Busy condition register to indicate Burst Bucket Full as the reason for Busy State. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision49/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 54===== ======New Sparse mode====== A new semi-multiple event buffer scheme is allowed. This allows a second event to be captured in the multi-event buffers even if sparse mode is enabled. Special care has to be taken to configure the number of buffers and the dead-time following the first of the possible two consecutive events. A new registers has been added: # Trigger Mode (address 0x2019) A new status bit has been added to the Busy condition register to indicate that two events happened, and are now being read-out. The use of this feature requires proper setting of registers, as described in the following: # Set the no of multi-event buffers to 2 (rcu-sh w 0x2009 0x02) # Set the L0 trigger time-out large enough to cover drift-time and SCEVL (for example to 200 us) (rcu-sh w 0x2008 0x14) # Enable the new sparse mode (rcu-sh w 0x2019 0x02) ======Other changes====== # The buffers-in-use count of the Busy Condidion Register is now updated correctly in busy_controller.vhd. # bb_bus_read now works correctly in busybox_tb_pkg. # Fixed R/W bug of register 0x2008 (introduced in rev. 49) ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision54/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 55===== ======L1 time====== RCU firmware with the bug fix related to reading and writing the event FIFO has been tested and used at P2 for a number of test done to check the multi event buffer functionality. Erroneous behaviour of trigger receiver module is no more observed neither at P2 nor in the RCU - Lab. ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision55/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 57===== ======Trigger Receiver L1 timer====== The programmable time-out following the start of a trigger sequence now starts on L1A instead of Trigger module busy output (L0 trigger time-out). ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision57/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 58===== ======Using Trigger Receiver Module v 1.6 (20.01.2012)====== * Single l2 messages does not generate CDH * Added Extended L2 time window to allow for CDH+payload if L2 message comes in boundary regions of the legal l2 window. This includes new register. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision58/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 63===== ======Using Trigger Receiver Module v 1.9 (17.08.2014)====== * New trigger classes with additional words for Alice CDH version 3 * Event FIFO is changed from Xilinx core IP to a generic component (inferred memory) This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1_solo.bit busybox_fpga1_solo.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/revision63/busybox_fpga2.bit busybox_fpga2.bit] =====Revision 65===== ======Using Trigger Receiver Module v 1.9 (30.06.2015)====== * New trigger classes with additional words for Alice CDH version 3 * Register map is set according to RCU2:'''Old trigger address map is not valid'''. New address map is found here[[:File:TTCrx_receiver_v2.0.2.pdf]]. * Reduced number of links on Busy box to comply with new DAQ architect (40 Links). TPC has 36 links (18x2=36), 4 additional links are kept for EMCAL. * There is only one FPGA needed to work so FPGA1 will be programmed. * -- Hardware note: In this release busy signal from FPGA2 is not used and related I/Os are disabled in Xilinx constraint file. ======Logical address mapping to physical connectors on busy-box====== * Reference point is GREEN LIGHT on connector side of the busy box (set at LEFT): D: Down, U: Up, L: Left. [[File:Bb_mapping.jpg]] 0x2100:DL1 0x2101:DL2 0x2102:DL3 0x2103:DL4 0x2104:UL1 0x2105:UL2 0x2106:UL3 0x2107:UL4 0x2108:DL5 0x2109:DL6 0x210A:DL7 0x210B:DL8 0x210C:UL5 0x210D:UL6 0x210E:UL7 0x210F:UL8 0x2110:DL9 0x2111:DL10 0x2112:DL11 0x2113:DL12 0x2114:UL9 0x2115:UL10 0x2116:UL11 0x2117:UL12 0x2118:DL13 0x2119:DL14 0x211A:DL15 0x211B:DL16 0x211C:UL13 0x211D:UL14 0x211E:UL15 0x211F:UL16 0x2120:DL17 0x2121:DL18 0x2122:DL19 0x2123:DL20 0x2124:UL17 0x2125:UL18 0x2126:UL19 0x2127:UL20 This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision65/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/fpga2_dummy.bit fpga2_dummy.bit] =====Revision 66===== ======Using Trigger Receiver Module v 2.1 (06.06.2016)====== [https://twiki.cern.ch/twiki/bin/viewauth/ALICE/TPC_RCU2_TTC_Module Click for Trigger Receiver updates] *This release only updates the trigger receiver module and firmware is tested to receive all valid trigger sequences. *Please perform a complete integration (DAQ+RCU+BusyBox) test in lab before using it at experiment. This BusyBox firmware version has been compiled with ISE version 13.2 ======Download====== *[http://web.ift.uib.no/firmware/BusyBox/revision66/busybox_fpga1.bit busybox_fpga1.bit] *[http://web.ift.uib.no/firmware/BusyBox/fpga2_dummy.bit fpga2_dummy.bit] ==== DCS board firmware for BusyBox ==== The DCS board in the BusyBox uses special firmware. See [[Electronics for the Time Projection Chamber (TPC)#Download_Section|Electronics for the TPC]] ====Generating FPGA configuration files from source code==== # Check out the desired revision from the SVN repository. # Navigate to .../busybox_firmware/trunk/ISE_projects # Run the TCL script named bbiseproject.tcl with Xilinx' TCL interpreter. The script takes three commandline arguments :<br> #*<tt>fpga_version</tt> - see [[#BusyBox FPGAs]] #*<tt>source_dir</tt> - where the source code is located. Including constraints and cores. #*<tt>project_dir</tt> - location where project is created. Note folder has to exist and should not already contain an ISE project. #:Example: <code>D:\busybox_firmware\trunk\ISE_projects>xtclsh bbiseproject.tcl busybox_fpga1_solo ..\source test<br></code> #Generate the cores with CoreGen (If it not already done) #:This can be done by using the CoreGen GUI or by invoking coregen in batch mode from the commandline. To use the GUI; start coregen while in <tt>.../busybox_firmware/trunk/source/cores</tt>. #: For batch mode : <tt>.../busybox_firmware/trunk/source/cores/coregen -b 'core'.xco</tt> replace 'core' with real name for all *.xco-files. #: Example with DOS for loop: <tt>D:\busybox_firmware\trunk\source\cores>FOR %i IN (*.xco) DO coregen -b %i</tt> #Open the project with ISE Project Navigator. #Run process 'Generate Programming File' <br> == Related documents for BusyBox == #[[Media:BusyBoxUserGuide.pdf|BusyBox User Guide (updated for FW rev 41)]] #[[Electronics_for_the_Time_Projection_Chamber_%28TPC%29#RCU_Trigger_Receiver_Module|RCU Trigger Receiver Module]] #[[Media:master_thesis_magne_munkejord.pdf|Master Thesis, Magne Munkejord]] #[[Media:jalme_phd-thesis.pdf|PhD Thesis, Johan Alme]] #[[Media:SelectMAP_Kernel_Module.pdf|SelectMAP Kernel Module report by J.K.Bernhardsen, J.M. Langeland, S. Skjerveggen (in norwegian)]] #[http://web.ift.uib.no/firmware/BusyBox/BusyBoxFeeServer.pdf BusyBox FeeServer] [[Category:Alice]] [[Category:Trigger]] 9becbd61c568f204f29716bcf0429391d772b0ae 0 555 2305 2016-05-06T17:08:50Z Mer020 87 Created page with "To create a butterfly curve, for example for characterizing SRAM read and hold margins, simulate a single DC sweep (one source, one sweep) on a input. Plot both the input (sho..." wikitext text/x-wiki To create a butterfly curve, for example for characterizing SRAM read and hold margins, simulate a single DC sweep (one source, one sweep) on a input. Plot both the input (shows up as a straight line for a linear DC sweep) and the output (shows up as the DC response of your circuit). Have both plots in the same subwindows. go to Axis -> Y vs Y choose the first trace go again to Axis -> Y vs Y choose the second trace Put both results in the same plot, and you are finished. 75349451e67f45a67c14530cdd3d4b691fac4fb8 2306 2305 2016-05-06T17:10:47Z Mer020 87 wikitext text/x-wiki To create a butterfly curve, for example for characterizing SRAM read and hold margins, simulate a single DC sweep (one source, one sweep) on a input. Plot both the input (shows up as a straight line for a linear DC sweep) and the output (shows up as the DC response of your circuit). Have both plots in the same subwindows. go to Axis -> Y vs Y choose the first trace, press ok. go again to Axis -> Y vs Y choose the second trace, press ok. Put both results in the same plot, and you are finished. 972189926886a64d3d9fae2570344a9c8a92a360 6 556 2308 2016-05-09T09:42:20Z Are033 82 bb_connectros.jpg wikitext text/x-wiki bb_connectros.jpg aaa25dd6367ef634596143e0a037ef82989e9974 6 557 2312 2016-05-09T12:41:52Z Are033 82 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 225 2315 1055 2016-05-10T09:10:36Z Nfyal 26 /* Talks */ wikitext text/x-wiki == HEP outreach == === Talks === =TedX talk on antimatter by a former group member Lillian Smestad ! http://mypages.iit.edu/~tedxiit/ , alternatively, here is the direct link: http://livestream.com/TEDx/IIT2016= === Images === === Links === 64a851fe8a9af41642fb192544f562dd468ef642 2316 2315 2016-05-10T09:11:06Z Nfyal 26 /* Talks */ wikitext text/x-wiki == HEP outreach == === Talks === =TedX talk on antimatter by a former group member Lillian Smestad ! http://mypages.iit.edu/~tedxiit/ , alternatively, here is the direct link: http://livestream.com/TEDx/IIT2016 === Images === === Links === ccc4f6ab066eaa28ad4703e4f6232f8f5dde6b2d 0 203 2317 1883 2016-05-13T09:50:10Z Ave082 33 wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23, 28 or 57 to Blandonnet (stops under the bridge, go up and to the right in the middle of the stairs), and then change to the tram 18 "CERN" or Y "Val-Thoiry". Check [http://www.tpg.ch tpg.ch] for the timetable. Get off at the stop opposite the large wooden globe. To get to the busses from the airport you go left and into the area leading to the trains. Take the escalator to the second floor and the bus stop is right outside. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == To get into CERN if you don't have anybody to pick you up it is usually easiest to show your CERN contract to clerk at the visitors office, [http://building.web.cern.ch/map/building?bno=31 map]. * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, [http://building.web.cern.ch/map/building?bno=561 map]. *Alice registration. ===CERN car=== You need to get a CERN car driving authorization from [https://edh.cern.ch/Document/General/DA here]. A scanned copy of your license needs to be attached. To get the license, you need security course, level 1+2, see below. The car is usually located outside the Bergen Office (plate number GE 603658, car number 3948), but could also be located at the parking area by building 400. The key is in the office. To fuel up, go to the CERN gas station at building 130 on Meyrin side. Use the badge attached to the key to login and enter the current mileage of the car. For other information [http://smb-dep.web.cern.ch/en/Mobility/Vehicles_with_without_logo see]. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 0326b657aacd52ea7c09697729935c5fe5d4c18d 2318 2317 2016-05-13T09:51:55Z Ave082 33 /* CERN car */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23, 28 or 57 to Blandonnet (stops under the bridge, go up and to the right in the middle of the stairs), and then change to the tram 18 "CERN" or Y "Val-Thoiry". Check [http://www.tpg.ch tpg.ch] for the timetable. Get off at the stop opposite the large wooden globe. To get to the busses from the airport you go left and into the area leading to the trains. Take the escalator to the second floor and the bus stop is right outside. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == To get into CERN if you don't have anybody to pick you up it is usually easiest to show your CERN contract to clerk at the visitors office, [http://building.web.cern.ch/map/building?bno=31 map]. * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, [http://building.web.cern.ch/map/building?bno=561 map]. *Alice registration. ===CERN car=== You need to get a CERN car driving authorization from [https://edh.cern.ch/Document/General/DA here]. A scanned copy of your license needs to be attached. To get the license, you need security course, level 1+2, see below. The car is usually located outside the Bergen Office (plate number GE 603658, car number 3948), but could also be located at the parking area by building 400. The key is in the office. To fuel up, go to the CERN gas station at building 130 on Meyrin side. Use the badge attached to the key to login and enter the current mileage of the car. The cost is charged to the team account. For other information [http://smb-dep.web.cern.ch/en/Mobility/Vehicles_with_without_logo see]. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) 61cdcdcd6b31e9feccadb33c600851a69024144b 2319 2318 2016-05-13T09:58:18Z Ave082 33 /* CERN car */ wikitext text/x-wiki Here is some gathered information that should make it easier for those people who travel to CERN for the first time. Feel free to add & edit! == Documents to bring == * Filled CERN contract or CERN short term contract ** [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/CheckIn/RformE.pdf Normal Contract] NB! Your Teamleader has to sign the contract, the buget code has to be filled. Internal Address (Bergen office): Building 587, Ground Floor, R-031 NB2! You need to provide a valid health insurance document. For norwegians this is usually the EU health insurance card (Europeisk helsetrygdkort), which you can order online here: https://tjenester.nav.no/helsetrygdkort/forside.do * In addition it seems that you now need a filled ALICE registration form as well: ** http://aliceinfo.cern.ch/Collaboration/General/secretariat/NEWCOMERS/index.html * If you want a specific picture from you on your Cern card, then you have to bring it. Otherwise they take a picture of you when making the card. == Where to stay == '''At CERN''' *[http://housing-service.web.cern.ch/housing-service/hostelwelc.html CERN hostel]. Hint: If it is full, you can still get rooms here on a day-to-day basis. You have to show up at the reception each day when it opens (7.30), and then you usually get an extension of your stay. If you don't have a bed for the night, you can ask the guard later in the evening (after 22/23:00). He gets a list and keys of the empty hostel rooms. These you can usually also get extended. '''St.Genis (Lies between CERN and ALICE) ''' * [http://balladins.eu/fiche_hotel.php?id=166 Balladins] * [http://www.hotel-sofia.com/ Hotel Sofia] * [http://www.kyriad.com/hotel/en/FRA22466.htm Kyriad Hotel] '''Between CERN and Geneve''' * [http://www.etaphotel.com/gb/hotel-5653-etap-hotel-geneve/index.shtml Etap Hotel] == How to get to CERN == At the airport, just before you leave the luggage claim area, there are special machines where you can get a free public transport ticket. To/from airport there are now several alternatives: The Y bus has been prolonged to Ferney, passing by the airport (thus giving a direct connection (with a detour through the ZIMEYSA area) between CERN and the airport. This lines runs once per hour - twice per hour in rush hours. Or you can take bus 23, 28 or 57 to Blandonnet (stops under the bridge, go up and to the right in the middle of the stairs), and then change to the tram 18 "CERN" or Y "Val-Thoiry". Check [http://www.tpg.ch tpg.ch] for the timetable. Get off at the stop opposite the large wooden globe. To get to the busses from the airport you go left and into the area leading to the trains. Take the escalator to the second floor and the bus stop is right outside. There is also a CERN shuttle bus to/from the airport ([http://gs-dep.web.cern.ch/en/content/Shuttle/Circuit4 timetable]), but you need to have a CERN card already to use it. == What to do first at CERN == To get into CERN if you don't have anybody to pick you up it is usually easiest to show your CERN contract to clerk at the visitors office, [http://building.web.cern.ch/map/building?bno=31 map]. * Go to the Users office, [http://building.web.cern.ch/map/building?bno=USERS+OFFICE:+61-R-010 map], to get your contract fixed, afterwards you get your key card from the registration office, [http://building.web.cern.ch/map/building?bno=55 map]. * To rent a bicycle, go to [http://ep-div-smi.web.cern.ch/ep-div-smi/Service_point.html Service Point] [http://building.web.cern.ch/map/building?bno=124 map] '''[http://aliceinfo.cern.ch/Collaboration/General/secretariat/ ALICE secretariat]''' Go here, [http://building.web.cern.ch/map/building?bno=301 map], for *key to the Bergen Office (if you want this), Key number: RZ1052, [http://building.web.cern.ch/map/building?bno=561 map]. *Alice registration. ===CERN car=== You need to get a CERN car driving authorization from [https://edh.cern.ch/Document/General/DA here]. A scanned copy of your license needs to be attached. To get the license, you need security course, level 1+2, see below. The car is usually located outside the Bergen Office (plate number <s>GE 603658</s>, car number 4793), but could also be located at the parking area by building 400. The key is in the office. To fuel up, go to the CERN gas station at building 130 on Meyrin side. Use the badge attached to the key to login and enter the current mileage of the car. The cost is charged to the team account. For other information [http://smb-dep.web.cern.ch/en/Mobility/Vehicles_with_without_logo see]. For other tips, check out User's office [http://ph-dep-usersoffice.web.cern.ch/ph-dep-UsersOffice/ home page]. == To do shifts == * You need a security course, this you can do at [http://sir.cern.ch sir.cern.ch]. * Request access for the control room at [https://edh.cern.ch edh.cern.ch] --> Access Request. NB: Remember to press Send when you are done adding requests. For this you need a special EDH-password, you can get this from AIS-support (Call 78888 when at CERN). The rooms to request are: ALI-ACR and ALI-COF. Set start-date for todays date, but don't set anything for the end-date. * Here is the instructions for the shifts that you can take: http://aliceinfo.cern.ch/Collaboration/Run_Coordination/Run09/shift/ * There is a shuttle bus to P2 as well: http://gs-dep.web.cern.ch/gs-dep/groups/sem/ls/RegularShuttleTimetable.htm The next shift courses for DAQ-CTP-HLT are: * on Thursday 7th of October at 14h in room 160-1-009, * on Thursday 11th of November at 14h in room 160-1-009 Those who will attend will be able to book a shorter period of training ( 2 days instead of 4 days ). == ALICE shiftwork == * Have a look into the [http://alice-project-tpc-trd-shift-manual.web.cern.ch/alice-project-TPC-TRD-Shift-Manual/TPC_ShiftGuide_Mar10.pdf TPC&TRD shiftguide]. * [https://alihlt-gw0.cern.ch/doc/manuals/operator-manual.pdf HLT shiftguide] * Book your shifts at [[https://alicesms.cern.ch/ alicesms.cern.ch] * Remember to take a shift course and book the necessary shadow shifts. * You will need access to the ALICE logbook, [https://alice-logbook.cern.ch alice-logbook.cern.ch], ask the run coordinator for access. == Printing at Cern == Cern has many printers, free to use for every visitor. However the IT department of UiB only allows its own print servers to be installed on Klientdrift machines, and blocks every other non-UiB printserver. An exception has now been added for Cern printservers, but you have to follow this way of installing them (in Windows anyway - They might be not blocked under Klientdrift Linux): * Open an explorer and type the printername in the addressfield in this way: * "\\<printername>.print.cern.ch\<printername> * Then you should be prompted for your credentials, which you enter in the form "cern\username" - and your NICE password. For the printer in the corridor outside the Bergen office it looks like this: "587-R-COR.print.cern.ch\587-R-COR" [[User:Dfe002|Dominik]] 16:00, 3 December 2010 (UTC) a9abd354702855d50ade01b8579a30e82a056940 6 558 2320 2016-05-19T17:58:20Z Are033 82 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 559 2322 2016-05-20T09:51:33Z Mer020 87 Small list, hopefully helpful, made for the purpose of speeding up initial development for boundary scan testing. wikitext text/x-wiki To make an automated test setup for a new prototype pcb, a few things are needed. * Cable from XJlink to fit the prototype board. From 2x10 pin ribbon cable connector to TAP connection on the PCB. Pins 1,2,4 & 20 are reserved for VCC, NC, GND & GND on the XJlink. The rest is configurable. * Netslist of the prototype circuit, for fast setup of XJDeveloper. This can be omitted, but having a netlist will make things faster and easier. * BSDL file for the JTAG equipped IC's on the pcb. This is needed to set up the JTAG chain for the XJDeveloper. * XJTAG also provides a .h file for interfacing drivers with C links to api: [http://www.xjtag.com/XJAPI.h XJAPI.h] [http://www.xjtag.com/jtag-tools/xjapi-jtag-access.php XJAPI docs] [[Category:Mikroelektronikk]] [[Category:Programming]] [[Category:JTAG]] [[Category:XJTAG]] 861d6ed1adabad60cd3996d1f975bba25217d681 0 189 2323 1207 2016-05-20T09:57:01Z Mer020 87 Added link to XJTAG_for_new_prototypes wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 2.3 > Help > XJEase and XJDeveloper Tutorial This tutorial assumes you have a version 2.0 of the XJDemo board. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board. Refer to the schematic for the pinmapping for page 11 of the tutorial. # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. =Additional resources= [[XJTAG_for_new_prototypes]] [[Category:Mikroelektronikk]] c86ee47cbecc541f4cd5a554d1d0a0b61271b203 0 137 2324 2117 2016-05-27T12:37:04Z Nfo058 90 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Conferences === * [[From Higgs to Dark Matter 2014, in statu. nascendi, [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS is being evaluated now. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 24b57115896a79a1b6ae26fdaa26e8a925a08902 0 160 2325 2151 2016-05-27T12:48:40Z Nfo058 90 wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[Software workshop, 09/09-09]] [https://indico.cern.ch/event/472469/overview ATLAS analysis tutorial, 7-8 February 2016, Oslo ] [https://indico.cern.ch/event/465378/ ATLAS software tutorial ] [https://twiki.cern.ch/twiki/bin/view/AtlasComputing/ComputingTutorials ATLAS computing tutorials twiki] == Upcoming tutorials == [https://indico.cern.ch/event/524296/overview ATLAS software tutorial June 6-10, 2016 at CERN] == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] d61d3ea12fbb5b54c5e9fede0102e5b9b001d9c4 0 202 2328 2121 2016-08-23T08:18:40Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [http://www.k-state.edu/ksuedl/publications/Technote%201%20-%20Equivalent%20Noise%20Bandwidth.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] * [[Media:p-n_junctions.pdf Elementary Physics of P-N Junctions]] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] f6500b6f9b01ec8e6ccad1d2000da17fe2511c52 2329 2328 2016-08-23T08:21:15Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [http://www.k-state.edu/ksuedl/publications/Technote%201%20-%20Equivalent%20Noise%20Bandwidth.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice IV ==== LTspice IV is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice IV] [[Category:Mikroelektronikk]] 8310d34c2737c99417e44785c9312ffba80da4eb 0 21 2330 1615 2016-08-25T09:44:34Z Nfyku 4 Updating personell wikitext text/x-wiki == Goal == The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research. == Our projects == * [[PET Project]] ** [[Labview readout setup]] ** [[XYZ table setup]] ** [[Root analysis programs]] * [[Calorimeter Activities]] * [[CALICE]] * [[3D Detector Activities]] * [[phys117 - PET project]] == Who are we? == * Students: Arild, Zhou * Postdoctors: Ganesh, Trygve * Researcher: Heidi * Professors: Gerald, Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil] * Engineers: Attiq, Werner, Kåre == Our facilities == * The main laboratory is situated in the 3rd floor at the IFT, room 332 (55588306) * The soldering lab, room 334 * The clean room, room 324 * [[The muon spectrometer]] == Lab Equipment == * [[Lab Equipment]] list, how to's, equipment service log's etc... * [[Wishlist]] Put the things you will need for your projects here. == Health and Safety == * [[Retningslinjer for bruk av kapslede kilder ved IFT]] * [http://www.uib.no/poa/hms-portalen UIB HMS Portalen] == Resources == * Our [https://subversion.uib.no/repos/detectorlab/ SVN] * We can use this fileserver to store our collected data: ** Windows: \\ukl-felles\ift-kjernefys1\detectorlab ** Linux: /Data/ift/ift_kjernefys1/detectorlab == Recent talks == 04.11.09 * Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf] * Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf] * Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]] [[older presentations]] ==Documentation== In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab. == Meetings and conferences == * 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/) * 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/) == For internal use == [[material]] that can be used in official presentations. 49afe9a82a99a6c7501b4be7a49a68f008209188 0 111 2331 1619 2016-08-25T09:47:43Z Nfyku 4 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Number !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |2 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |1 |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |1 |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |4 |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |2 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |1 |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |1 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, 5 Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] | |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf manual] | |- |Caen N1471A |2 Ch programmable High Voltage PSU, 5.5 kV / 300 µA |[http://www.caen.it/servlet/checkCaenManualFile?Id=7746 manual] | |- |Tennelec TC244 |Amplifier |[ manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} = XY stages = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manual !Software !default values |- |2 x Zaber T-LSM200B |Motorized Stage, 200 mm travel, RS-232 plus manual control |[http://www.zaber.com/wiki/Manuals/T-LSM wiki], [http://www.zaber.com/documents/T-LSM-manual.pdf pdf] |[http://www.zaber.com/wiki/Software software] |[http://www.zaber.com/support/?tab=Device%20ids#tabs def. val.] |} cfa854ba3b1eb9de88dee939587c2aed05758e75 2332 2331 2016-08-25T09:53:22Z Nfyku 4 wikitext text/x-wiki = Power Supplies = == High Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |CAEN 40 Channel High Voltage System |High Voltage DC power supply equipped with 4x POS 200V, 4x NEG 200V, 4x POS 2000V and 2 x POS 15 kV outputs |[[CAEN 40CH HV PSU]] | |- |} == 'Medium' Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !I/O !borrowed to |- |Elektro Automatik EA-PSI 6150-01 |150 V, 1,2A linear DC power supply |RS232 | |} == Low Voltage == {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Number !Description !I/O !Drivers !Notes !borrowed to |- |TTi EL155 |2 |15V, 5A linear DC power supply | | | |2x Anja |- |TTi EL302D |1 |30V, 2A dual linear DC power supply | | | |1x Anja |- |TTi EL302Tv |1 |30V, 2A triple linear DC power supply | | | |1x Kjetil |- |TTi QL355TP |4 |15V, 5A / 35V, 3A / 35V, 0,5A + Aux, dual DC power supply |GPIB, RS232, USB |[http://www.tti1.co.uk/downloads/usb-drivers/TTi-USB-FTDI-v2_06_02.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QL-v1.5.1.zip LabView] |[https://wikihost.uib.no/ift/images/2/24/ITTQL355TPmanual.pdf Users manual] |1x Anja |- |TTi QPX1200 |2 |60V, 50A linear DC power supply |USB, RS232, LAN |[http://www.tti-test.com/go/qsx/qsx-downloads/lv-cvi-QPX-v1.0.2.zip USB], [http://tti1.co.uk/downloads/drivers/lv-cvi-QPX-v1.0.2.zip Labview] |[https://wikihost.uib.no/ift/images/1/17/ITTQPX1200manual.pdf Users manual] |1x Kjetil, 1x Lijiao |- |Oltronix Labpac 800T |1 |15V/35V, 2A/1,1A | | | | |- |ITT AX 322 |1 |2x 30V, 2,5A | | |Noisy | |- |} = Standalone measuring = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How to's !I/O !borrowed to |- |Tektronix MSO4034 |Mixed Signal Oscilloscop, 350 Mhz, 2,5Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB |ELab 4th floor |- |Tektronix MSO4104 |Mixed Signal Oscilloscop, 1 Ghz, 5 Gs/s |[https://wikihost.uib.no/ift/images/5/58/Tek4000user.pdf User manual] [https://wikihost.uib.no/ift/images/5/58/Tek4000prog.pdf Programmers manual] |LAN, USB | |- |Agilent MSO7054A |Mixed Signal Oscilloscop, 500 Mhz, 4Gs/s |[http://cp.literature.agilent.com/litweb/pdf/54695-97014.pdf Users guide] [http://www.home.agilent.com/upload/cmc_upload/All/7000_series_prog_guide.pdf Programmers guide] |LAN, USB | |- |Keithley 2700 |Multimeter / Data Acquisition System, 20 Channel |[https://wikihost.uib.no/ift/images/4/4f/Keithley2700.pdf Users manual] |GPIB, RS232 | |- |Keithley 2100 |6 1/2 Digit Multimeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2100.pdf Users manual] |USB | |- |Keithley 2635A |200V / 1fA Sourcemeter |[https://wikihost.uib.no/ift/index.php/File:Keithley2635a.pdf Reference manual] |GPIB,LAN,TSP,RS232 | |} = Pulse Generators = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !I/O !borrowed to |- |Agilent 33250A |80 Mhz Arbitrary Function Waveform Generator |[http://cp.literature.agilent.com/litweb/pdf/33250-90002.pdf Users manual] |GPIB, RS232 |1x Lijiao |- |Tektronix AFG3252 |240 Mhz Arbitrary Function Waveform Generator |[https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252usman.pdf Users manual] [https://wikihost.uib.no/ift/images/e/e6/TektronixAFG3252progman.pdf Programmers manual] |USB, GPIB | |- |Philips PM 5715 |50 Mhz Pulse / Waveform Generator | | | |- |} = Amplifiers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Phillips Scientific 6954 |Wideband Amplifier, Gain: 100, Input Voltage: 10-28V. |[http://www.phillipsscientific.com/pdf/6954ds.pdf Info] | |- |Ortec VT120 |Amplifier, Gain: 200, Input Voltage: 12V. |[http://www.ortec-online.com/pdf/vt120.pdf Info] | |} = VME devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's !borrowed to |- |Caen V2818 |PCI bridge to VME controller |[https://wikihost.uib.no/ift/images/a/a1/Caen2818usman.pdf Users manual] | |- |Caen V2718 |VME controller |[https://wikihost.uib.no/ift/images/2/26/Caenv2718usman.pdf Users manual] | |- |Caen V1729a |14 bit, 4 channel ADC |[https://wikihost.uib.no/ift/images/b/b0/Caenv1729ausman.pdf Users manual] | |- |Caen V965a |QDC |[https://wikihost.uib.no/ift/images/d/d3/Caenv965ausman.pdf Users manual] | |- |National Instruments VME-MXI-2 |VME controller | | |- |Atlas TPLL |Turbo Pixel Low Level card (TPLL) |[http://physik2.uni-goettingen.de/~jgrosse/TurboDAQ/#PLLPCC TPLL&TPCC Info] | |} = NIM devices = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manuals !borrowed to |- |Caen N957 |8k Multi Channel Analyzer + ADC |[https://wikihost.uib.no/ift/images/d/db/Caenn957usman.pdf manual] | |- |Caen N1471A |2 Ch programmable High Voltage PSU, 5.5 kV / 300 µA |[http://www.caen.it/servlet/checkCaenManualFile?Id=7746 manual] | |- |Tennelec TC244 |Amplifier |[http://web.ift.uib.no/~kjetil/wiki/Tennelec_TC244.pdf manual] | |} = Photomultipliers = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !How To's |- |2 x Hamamatsu H6780-02, S.NO: 0003 & 0004 |Photomultiplier Module, Input Voltage: 15V, Gain: 1:10E4, Gain Control Voltage: 0,25-0,9 V. Max output current: 100uA! |[[Photomultipliers]] |} = XY stages = {| border="1" cellpadding="5" cellspacing="0" !Equipment Name !Description !Manual !Software !default values |- |2 x Zaber T-LSM200B |Motorized Stage, 200 mm travel, RS-232 plus manual control |[http://www.zaber.com/wiki/Manuals/T-LSM wiki], [http://www.zaber.com/documents/T-LSM-manual.pdf pdf] |[http://www.zaber.com/wiki/Software software] |[http://www.zaber.com/support/?tab=Device%20ids#tabs def. val.] |} 5c3d6b194da054f3f47d17bf3ea073a0792dfcdf 0 461 2333 2041 2016-09-02T07:39:35Z Nfyku 4 changed from csh to sh and from /prog to /eda wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 source /eda/cadence/cadence_init.sh tsmc_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. 7. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 8. To check and save the schematic, press 'x' or click the "Check and save" icon. 9. If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 10. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 11. Choose "Create > Test..." select the cell to simulate. 12. Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. 13. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 14. Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. 5ce16e5aa061a2b5f419ba60b3b2cec727e6f302 2369 2333 2016-11-08T12:24:50Z Nfyku 4 wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 source /eda/cadence/cadence_init.sh First time you should add the following line to you cds.lib file before starting the design environment DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf Virtuoso Mixed Signal Design Environment is started by issuing this command: tsmc_cds_start In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. # Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] # Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. 238956cfd8d5f8c7acf74ebe6c79a3c6b7f0c37c 2370 2369 2016-11-08T12:25:52Z Nfyku 4 wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 source /eda/cadence/cadence_init.sh First time you should add the following line to your cds.lib file before starting the design environment. If the ~/cds.lib doesn't exist, just create it. DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf Virtuoso Mixed Signal Design Environment is started by issuing this command: tsmc_cds_start In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. # Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] # Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. e2804d42b1313a4a621dd56d0709d374a73aaedd 0 217 2334 2122 2016-09-13T08:46:07Z Nfyku 4 wikitext text/x-wiki === Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin === <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vo as a function of Vin % Only Cgd is considered (Zc) % Kjetil Ullaland syms s Vin Vo Vgs Zc gm Rl Rs R eq1='(Vo-Vgs)/(R+Zc)+gm*Vgs+Vo/Rl=0'; eq2='(Vgs-Vo)/(R+Zc)+(Vgs-Vin)/Rs=0'; eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); disp('KCL for circuit node 1:'); pretty(eq1); disp('KCL for circuit doc prettynode 2:'); pretty(eq2); disp('Solve for Vgs'); vgs_solved=solve(eq2,Vgs); pretty(simplify(vgs_solved)); disp('Solve for Vo(vin)'); eq3=subs(eq1,Vgs,vgs_solved); Vo_solved=solve(eq3,Vo); pretty(simplify(Vo_solved/Vin)) </pre> === Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is === <pre> % Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 % to find Vo as a function of Is % Kjetil Ullaland, 2015 syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz; %% With feedforward capacitor eq1=sym('(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/Zc+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=subs(eq1,V1,solV1); SolVo=simplify(solve(eq3,[Vo])); disp('With capacitor only in feedforward loop'); pretty(simplify(SolVo/Is)); %% With series resistor and capacitor in feedforward loop eq1=sym('(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=simplify(subs(eq1,V1,solV1)); SolVo=solve(eq3,[Vo]); disp('With series resistor and capacitor in feedforward loop'); pretty(simplify(SolVo/Is)); </pre> e9bc7a21efbec6a0dc3897283695d2b8755e5b1b 0 234 2335 2118 2016-09-23T14:58:52Z Nfyst 67 /* Defended Master theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 -[[File:thesis_Olausen.pdf]] * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Opservation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] c105a3610afa6549b1405668d0ae93b124ad503d 2338 2335 2016-09-23T15:41:51Z Nfyst 67 /* Defended Master theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] e49cc7f79470f97ccb058bcdccc6279766634ce2 2339 2338 2016-09-23T16:11:45Z Nfyst 67 /* Defended Master theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] 239631edf93728d9591acd6a25bf19b40eb3cc9d 2345 2339 2016-09-23T23:39:25Z Nfyal 26 /* Defended PhD theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] 64c776737139a5787b282abd9be99452bf367dbf 2376 2345 2016-12-22T00:46:51Z Nfyal 26 /* Defended PhD theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] e530d9445c58218c2abbc9048f0f74a5c230096a 6 560 2336 2016-09-23T15:00:18Z Nfyst 67 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2337 2336 2016-09-23T15:07:58Z Nfyst 67 Nfyst uploaded a new version of [[File:MasterSimenHellesund.pdf]] wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 139 2340 2136 2016-09-23T22:08:47Z Nfyal 26 /* Seminar and meeting information */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/7495/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2016 === Nordic b-annual particle physics meeting, please register before 15 december and book your hotel before 1st of December: http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 4b43ebdd8572f6caf71a57809f453e1abdac2057 2356 2340 2016-09-24T04:00:44Z Nfyal 26 /* 2016 */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/7495/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2016 === * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] e6ec7f974f8c3682b25d9e1f73195a0c93d57ed4 2362 2356 2016-10-24T13:03:02Z Nfyal 26 /* 2016 */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/7495/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) == 2017 == EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] e2129cec7b7df6d9d7991d1f97cf91aba400eebb 2363 2362 2016-10-24T13:06:17Z Nfyal 26 /* 2017 */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/7495/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] a28756b6c6872f9203e5658d771732be9fa55d4e 2365 2363 2016-10-24T13:08:08Z Nfyal 26 /* 2017 */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics) https://indico.cern.ch/category/7495/ Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here: https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] bb10aadc53ee4fd2b4c82b6d32005ddc21b328af 2372 2365 2016-11-15T16:33:28Z Nfyal 26 /* Seminar and meeting information */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics). This includes 2016-2017 Bergen-Oslo meetings. https://indico.cern.ch/category/7495/ Old and not updated Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here (I still keep it for a while): https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 637f5b60e82e8fc30d836d5da0fcec5aeea90f01 0 137 2341 2324 2016-09-23T23:22:23Z Nfyal 26 /* Particle Physics */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === *[[ The Dark Side of the Universe, DSU2016 25-29 July 2016 https://indico.cern.ch/event/459881/ ]] *[[Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 ]]* * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 40b4402a3b5535ec00c50533239237c1b5fcb3a3 2342 2341 2016-09-23T23:23:53Z Nfyal 26 /* Local Conferences */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 24260f5ed80defdcad615a4f63db17349b3532c9 2347 2342 2016-09-24T02:07:56Z Nfyal 26 /* Particle Physics */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] b46091ace06fedacc8b2bc5ced6afc0e2233c815 2348 2347 2016-09-24T02:11:10Z Nfyal 26 /* Particle Physics */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 717cc78e573c40078989e9aaa3585496020d926f 2350 2348 2016-09-24T03:47:14Z Nfyal 26 /* Particle Physics */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 8cef6aeaf44442584394b95cf878e152eda5d566 2351 2350 2016-09-24T03:48:52Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 3ca89a81becb3b04ca630d321d7e97159ac63995 2352 2351 2016-09-24T03:51:54Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] f72d727d64bc176036d9104235c4fbc5ac662ef8 2353 2352 2016-09-24T03:52:30Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] Changed by AL 25/09/2015 Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] 381b93810291298e054f7b9eeee7797079b03f8c 2354 2353 2016-09-24T03:56:08Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] Changed by AL 25/09/2015 * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] Last changes: [[User:Tbu082|Tbu082]] 16:30, 10 March 2009 (CET) [[Category:Particle Physics]] b3ca996f8c0fc081736636460ab6f715b784399b 2355 2354 2016-09-24T03:57:09Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 3623deaa14a350bff22f7d164db4ad9ea39c9b62 2357 2355 2016-09-25T00:53:02Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] e58026c249b786bd0403b769eb714b0fb1802dc3 2358 2357 2016-09-25T01:01:34Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 1392961632d47dce1db48277066d22aab75f535f 2359 2358 2016-09-26T02:57:39Z Nfyal 26 /* Misc and AoB */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] f506f67a99f75f2ed2691ad261c0c1e658c09e82 0 160 2343 2325 2016-09-23T23:27:12Z Nfyal 26 /* Upcoming tutorials */ wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[Software workshop, 09/09-09]] [https://indico.cern.ch/event/472469/overview ATLAS analysis tutorial, 7-8 February 2016, Oslo ] [https://indico.cern.ch/event/465378/ ATLAS software tutorial ] [https://twiki.cern.ch/twiki/bin/view/AtlasComputing/ComputingTutorials ATLAS computing tutorials twiki] == Upcoming tutorials == [https://twiki.cern.ch/twiki/bin/view/AtlasComputing/SoftwareTutorial?redirectedfrom=AtlasComputing.RegularComputingTutorial Regular ATLAS Computing tutorials wiki] == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] 16d5a5dcefebea3700f9325d7344adc4537d53e4 2344 2343 2016-09-23T23:27:54Z Nfyal 26 /* Previous tutorials */ wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[Software workshop, 09/09-09]] [https://indico.cern.ch/event/524296/overview ATLAS software tutorial June 6-10, 2016 at CERN] [https://indico.cern.ch/event/472469/overview ATLAS analysis tutorial, 7-8 February 2016, Oslo ] [https://indico.cern.ch/event/465378/ ATLAS software tutorial ] [https://twiki.cern.ch/twiki/bin/view/AtlasComputing/ComputingTutorials ATLAS computing tutorials twiki] == Upcoming tutorials == [https://twiki.cern.ch/twiki/bin/view/AtlasComputing/SoftwareTutorial?redirectedfrom=AtlasComputing.RegularComputingTutorial Regular ATLAS Computing tutorials wiki] == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] 00cec019e9d99daa37c45196be5e99f4ac7f745e 6 561 2346 2016-09-23T23:40:24Z Nfyal 26 PhD Thesis of Orjan Dale, 2016 wikitext text/x-wiki PhD Thesis of Orjan Dale, 2016 6bc9525d17b50eaf2db946417338783d54edf98c 6 562 2349 2016-09-24T02:12:08Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 202 2360 2329 2016-09-28T11:41:14Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [http://www.k-state.edu/ksuedl/publications/Technote%201%20-%20Equivalent%20Noise%20Bandwidth.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] ae74307e64675199d30e328ae4b2e1684ba6cfce 0 223 2361 918 2016-09-28T11:42:00Z Nfyku 4 wikitext text/x-wiki == Øvingsoppgaver PHYS222== === Problem 3.4 from Gray et.al. === For the common-source amplifier of Fig 3.12, calculate the small-signal voltage gain and the bias values of Vi and Vo where the small-signal voltage gain is unity with the transistor operating in the active region. [[Spice deck]] == Øvingsoppgaver PHYS223== === Estimering av delay === Du skal i denne oppgaven konstruere en inverter av transistorer, lage symbol på den for så å finne propogation delayet ved hjelp av simulering. Du skal også finne delayet for en Fan Out of Four FO4, en statisk flipflop og en dynamisk flipflop. 1. Følg tutorialet [[IC_studio#Tutorial_for_konstruksjon_av_inverter_og_symbol]] eller prøv deg frem selv for å lage en inverter med tilhørende symbol i ICstudio. 2. Lag et nytt skjema der du legger inn inverteren, signal kildene og slikt, bruk en inverter som last. 3. Simuler og finn tpdr og tpdf 4. Lag til en inverter til under som har fire parallelle invertere som last 5. Simuler og finn tpdr og tpdf 6. Lag en dynamisk flipflop som vist i figur 7.19a s405 i Weste et.al. 7. Simuler og finn tpdr og tpdf om du vil kan du og prøve å finne ut setup tiden ved å sende innsagnelet inn litt før klokken. Du vil kunne se at utsignalet blir liggende på et mellomnivå i en del av pulsen. 8. Lag en latch fra transistorer med tilhørende symbol. Se figur 7.18 s405 i Weste et.al. 9. Gjør 6. og 7. for en statisk flipflop med det nye symbolet. Se figur 7.19b s405 i Weste et.al. 10. Regn ut path delay for den dynamiske og statisk flipflopen, bruk unit kapasitanser. 11. Prøv å bruke kondensatorene oppgitt av simuleringen for å se om du får samme delay som simuleringen. [[Tips]] [[Category:Mikroelektronikk]] d54fecb52468c6605496dacdb86716a10f33082f 6 563 2364 2016-10-24T13:06:52Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 564 2366 2016-10-24T13:09:41Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 472 2367 2106 2016-11-08T09:19:36Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. First chose a parent directory, e.g. cd ~/ihp Copy the user environment design and set general Cadence environment variables by doing: cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/work/skel . source /eda/cadence/cadence_init.sh Change cshrc.cadence in ~/ihp/skel/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment source ~/ihp/skel/cds/cshrc.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation [[Category:Mikroelektronikk]] 859e833e1485a90b44649ee0571b406d98ecd68c 2368 2367 2016-11-08T10:19:50Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. First chose a parent directory, e.g. cd ~/ihp Copy the user environment design and set general Cadence environment variables by doing: cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/work/skel . source /eda/cadence/cadence_init.sh Change cshrc.cadence in ~/ihp/skel/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment source ~/ihp/skel/cds/sh.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation [[Category:Mikroelektronikk]] c5c799f8c13a1311967958dbd5b9aee7a7a69fe3 2371 2368 2016-11-08T13:25:14Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. First chose a parent directory, e.g. cd ~/ihp Copy the user environment design and set general Cadence environment variables by doing: cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/work/skel . source /eda/cadence/cadence_init.sh Change cshrc.cadence in ~/ihp/skel/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment source ~/ihp/skel/cds/sh.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] 87cf4f5bde7a31afd931163fcded0592a43ab6cb 0 1 2373 1671 2016-11-16T13:14:33Z Nfyku 4 La inn teknisk avdeling wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] * [[DAMARA]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [[Nano Physics| Nano Physics Group]] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] cca7574740b75dd42461a3a37cf87dc451778329 2374 2373 2016-11-23T08:31:35Z Nfyku 4 Institutt for Fysikk og Teknologis Wiki wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] * [[DAMARA]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [http://wiki.uib.no/nanolab| Nano Lab] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 765f039e8d86c1c8a4b4b692f7c510f49d31fe90 2375 2374 2016-11-23T08:32:13Z Nfyku 4 wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[Space Physics group]] * [[DAMARA]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [http://wiki.uib.no/nanolab Nano Lab] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 89a4aa3b34a56973b0b2071d9d19c11355de67bc 6 565 2377 2016-12-22T00:48:16Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2378 2377 2016-12-22T00:51:29Z Nfyal 26 Nfyal uploaded a new version of [[File:PhDthesis-jan-lindroos.pdf]] wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 566 2379 2017-01-04T13:32:20Z Nfyku 4 Created page with "== Teknisk avdeling ved IFT == [[Instrumentliste]]" wikitext text/x-wiki == Teknisk avdeling ved IFT == [[Instrumentliste]] 75bde7bb4a2ec95451475914acdf6cc2dfa13cb4 0 1 2380 2375 2017-01-04T13:39:14Z Nfyku 4 Removing Space Physics Group page since it had no interesting info wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[Detector lab]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [[Particle Physics group]] * [[DAMARA]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [http://wiki.uib.no/nanolab Nano Lab] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 15436494c37eae6f5d405d506fbf7bca845ed2f0 2400 2380 2017-02-15T14:26:11Z Gge002 52 wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[DAMARA]] * [[Detector lab]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [http://wiki.uib.no/nanolab Nano Lab] * [[Particle Physics group]] * [[Strålevern]] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] ab17d6735e1bb1e445f25d94e8344540fd674760 0 567 2381 2017-01-04T14:05:40Z Nfyku 4 Created page with "==Forkortelsesliste== ===Grupper/Avdelinger=== {| |MICRO||Microelectronics group |- |TEKAVD||Teknisk Avdeling |- |DETLAB||Detektorlab |- |ALICE||ALICE eksperimentet |- |ATLAS..." wikitext text/x-wiki ==Forkortelsesliste== ===Grupper/Avdelinger=== {| |MICRO||Microelectronics group |- |TEKAVD||Teknisk Avdeling |- |DETLAB||Detektorlab |- |ALICE||ALICE eksperimentet |- |ATLAS||ATLAS eksperimentet |- |BCSS||Birkeland Centre for Space Science |- |} ===Instrumentkategorier=== {| |OSC||Oscilloskop||Oscilloscope |- |PSU||Strømforsyning||Power Supply |- |MET||Måleinstrument||System Source meter||Multimeter |- |ANA||Analysator||Spektrumsanalysator||Netverksanalysator |- |} a024b5f832bdc11f1df52234dd4aa6d66bf7a8f1 2382 2381 2017-01-04T14:35:18Z Nfyku 4 wikitext text/x-wiki ==Instrumenter== ==Forkortelsesliste== {| class="wikitable" !Type!!Manufacturer!!Model!!UiB-Serial and year!!Room!!Tag |- |Arbitrary Function Generator |Tektronix |AFG3252 |189999 (2010) |3XX |TEKAVD-DETLAB-GEN-001 |- |Oscilloscope |Tektroix |MSO4034 |189840 (2010) |3XX |TEKAVD-DETLAB-OSC-001 |} ===Grupper/Avdelinger=== {| |MICRO||Microelectronics group |- |TEKAVD||Teknisk Avdeling |- |DETLAB||Detektorlab |- |ALICE||ALICE eksperimentet |- |ATLAS||ATLAS eksperimentet |- |BCSS||Birkeland Centre for Space Science |- |} ===Instrumentkategorier=== {| |OSC||Oscilloskop||Oscilloscope |- |PSU||Strømforsyning||Power Supply |- |MET||Måleinstrument||System Source meter||Multimeter |- |ANA||Analysator||Spektrumsanalysator||Netverksanalysator |- |} ea0cc8152af67b9237f3fa304764641cd5c12460 2383 2382 2017-01-04T14:37:27Z Nfyku 4 wikitext text/x-wiki ==Instrumenter== {| class="wikitable" !Type!!Manufacturer!!Model!!UiB-Serial and year!!Room!!Tag |- |Arbitrary Function Generator |Tektronix |AFG3252 |189999 (2010) |3XX |TEKAVD-DETLAB-GEN-001 |- |Oscilloscope |Tektroix |MSO4034 |189840 (2010) |3XX |TEKAVD-DETLAB-OSC-001 |} ==Forkortelsesliste== ===Grupper/Avdelinger=== {| class="wikitable" |MICRO||Microelectronics group |- |TEKAVD||Teknisk Avdeling |- |DETLAB||Detektorlab |- |ALICE||ALICE eksperimentet |- |ATLAS||ATLAS eksperimentet |- |BCSS||Birkeland Centre for Space Science |- |} ===Instrumentkategorier=== {| class="wikitable" |OSC||Oscilloskop||Oscilloscope |- |PSU||Strømforsyning||Power Supply |- |MET||Måleinstrument||System Source meter||Multimeter |- |ANA||Analysator||Spektrumsanalysator||Netverksanalysator |- |} [[Category:Teknisk Avdeling]] 6573a1435b674e7c542e5f27ec329b755632bc12 2384 2383 2017-01-04T14:39:34Z Nfyku 4 /* Grupper/Avdelinger */ wikitext text/x-wiki ==Instrumenter== {| class="wikitable" !Type!!Manufacturer!!Model!!UiB-Serial and year!!Room!!Tag |- |Arbitrary Function Generator |Tektronix |AFG3252 |189999 (2010) |3XX |TEKAVD-DETLAB-GEN-001 |- |Oscilloscope |Tektroix |MSO4034 |189840 (2010) |3XX |TEKAVD-DETLAB-OSC-001 |} ==Forkortelsesliste== ===Grupper/Avdelinger/Labber=== {| class="wikitable" |MICRO||Microelectronics group |- |TEKAVD||Teknisk Avdeling |- |DETLAB||Detektorlab |- |ALICE||ALICE eksperimentet |- |ATLAS||ATLAS eksperimentet |- |BCSS||Birkeland Centre for Space Science |- |} ===Instrumentkategorier=== {| class="wikitable" |OSC||Oscilloskop||Oscilloscope |- |PSU||Strømforsyning||Power Supply |- |MET||Måleinstrument||System Source meter||Multimeter |- |ANA||Analysator||Spektrumsanalysator||Netverksanalysator |- |} [[Category:Teknisk Avdeling]] cb36220127f40f167992ba5b7b95d5a304176c4d 2385 2384 2017-01-05T08:16:35Z Nfyku 4 sortert alfabetisk wikitext text/x-wiki ==Instrumenter== {| class="wikitable" !Type!!Manufacturer!!Model!!UiB-Serial and year!!Room!!Tag |- |Arbitrary Function Generator |Tektronix |AFG3252 |189999 (2010) |3XX |TEKAVD-DETLAB-GEN-001 |- |Oscilloscope |Tektronix |MSO4034 |189840 (2010) |3XX |TEKAVD-DETLAB-OSC-001 |} ==Forkortelsesliste== ===Grupper/Avdelinger/Labber=== {| class="wikitable" |ALICE||ALICE eksperimentet |- |ATLAS||ATLAS eksperimentet |- |BCSS||Birkeland Centre for Space Science |- |DETLAB||Detektorlab |- |MICRO||Microelectronics group |- |TEKAVD||Teknisk Avdeling |} ===Instrumentkategorier=== {| class="wikitable" |ANA||Analysator||Spektrumsanalysator||Netverksanalysator |- |MET||Måleinstrument||System Source meter||Multimeter |- |OSC||Oscilloskop||Oscilloscope |- |PSU||Strømforsyning||Power Supply |- |} [[Category:Teknisk Avdeling]] 45f936c5f36e002e51c07eaafb127ccd8e0d3a86 0 279 2386 1836 2017-01-05T08:42:07Z Nfyku 4 wikitext text/x-wiki [[SSH innlogging]] Hvordan logge inn med ssh fra remote Windows-PC [[VNC]] Hvordan bruke VNC for å logge inn fra remote Linux-PC eller Windows-PC [[Xming]] Hvordan bruke Xming for å logge inn fra remote Windows-PC [[http://www.msc.rl.ac.uk/europractice/software/mentor.html Europractice Mentor Graphics Software Overview]] [[http://www.msc.rl.ac.uk/europractice/software/cadence.html Europractice Cadence Software Overview]] [[Cadence]] Hvordan installere Cadence [[gitlab]] Hvordan bruke gitlab [[Category:Mikroelektronikk]] eb31ca63cb20b17b475f72f39b3c3116d347244c 0 568 2387 2017-01-05T08:55:20Z Nfyku 4 Created page with "== Software repository == We use the '''gitlab''' server hosted by IT of University of Bergen. Further information: * [https://docs.gitlab.com/ce/gitlab-basics/README.html Gi..." wikitext text/x-wiki == Software repository == We use the '''gitlab''' server hosted by IT of University of Bergen. Further information: * [https://docs.gitlab.com/ce/gitlab-basics/README.html Gitlab basics] * [https://docs.gitlab.com/ee/workflow/README.html Gitlab workflow] == Development workflow == Every logged-in user can access the main repository, however only a small group of administrators has write access. To contribute, a user creates a ''fork'' from the repository. This is a copy where a single developer or a group of developers have full access. The main repository has the following branches: * '''production''': the latest production code, in this branch we have release tags * '''master''': the latest stable release * '''dev''': the development branch In addition to those main branches there can be ''feature'' branches where development happens detached from the main branches. A ''feature'' branch is based on the ''dev'' branch and has a limited lifetime. === Creating a project fork === A ''project fork'' or ''repository fork'' is a copy of the original repository where a user or a group of users has/have full control. All development in our project is carried out in the individual forks. Branches of project forks are merged back into the main repository by '''merge requests''', preferably via '''fast forward''' merges. That requires developers to rebase project forks to the main repository and resolve all conflicts before requesting a merge. [https://docs.gitlab.com/ce/gitlab-basics/fork-project.html How to fork a project] Your repository fork is your sandbox, you can do whatever you want. Unless you have your own rules at hand right now you can apply the following: * leave the ''master'' branch in sync with the main repository, do not make commits to it * commit your changes to the ''dev'' branch * if you start a new feature, and it's expected to take a while, make a ''feature'' branch, e.g. ''dev-feature'' and give the feature a name * synchronize regularly to the main repository by rebasing === Making local development copy === Clone directly from your development fork, replace ''user'' appropriately. '''Note''': the gitlab offers two modes for the link to be cloned, you can choose ''ssh'' (default setting) or ''https''. If you can not clone with the proposed default link, try option ''https://''. git clone https://user@gitlab.uib.no/asim/asdc.git This repository will get the name ''origin'' in your local clone. If you have cloned already from the main repository, the upstream link can be changed as follows cd <reponame> git remote set-url origin https://user@gitlab.uib.no/asim/asdc.git === Pushing to development fork === Once you have added commits to e.g. the '''dev''' branch, those commits can be ''pushed'' upstream to the fork. git push origin dev === Pull/Merge request === All updates to the main repository are made via ''merge requests'' (github refers to them as ''pull requests''). A merge request requires the code update to be in a mergable branch in a development fork. Merge request are also used widely to share ''work-in-progress'' with your colleagues and for code reviews. Mark such Merge request with "'''WIP:'''". ==== Preparation ==== In order to avoid conflicts, first the fork has to be updated to the main repository. The idea behind this is that all potential conflicts can be resolved by the developer with the best knowledge about the matter, while the maintainer can simple merge ''fast-forward''. ==== Example workflow for a Merge request ==== # Go to your gitlab user space at [https://gitlab.uib.no/user https://gitlab.uib.no/user] (replace ''user'' appropriately. # Find the project fork, e.g. in the list of projects associated with you from the upper main menu. # In the line with the many columns regarding the repository, click on the "+"-symbol on the right hand side and choose "New merge request" # Select project and branch for both source and target, and click "Compare branches and continue" # Review the list of commits in this merge request, give it a descriptive title and description, pick an assignee # Submit the merge request === Importing an external package === The project will use a couple of external packages which are hosted in a different master repository. Copies of such external packages can be added to the gitlab server under our project group to provide a consistent package. Here is a proposed workflow for importing a package which is already hosted in git. # Create new repository in the asim group or ask for creation, lets call it ''newPackage'' # Fork the repository to your user space # Clone the package you want to import #:<pre> git clone <some_external_link> newPackage # we give it the new name</pre> #:<pre> cd newPackage</pre> # Redirect upstream URL to the fork in your gitlab user space #:<pre> git remote set-url origin https://user@gitlab.uib.no/user/newPackage.git</pre> # Now make a forced push (option ''-f'') to import the repository to your fork #:<pre> git push -f origin</pre> # Create merge request to branch ''import'' (if not existing, ''master'' or any other appropriate branch) by following the instructions [[Documentation#Pull/Merge request | Pull/Merge request]] b5f3b9d11943794fbf9faac8c7e22528eac77ea3 0 33 2388 2274 2017-01-18T09:28:27Z Nfyku 4 wikitext text/x-wiki Mapping av alterabibliotek: <pre> vmap cyclonev /prog/altera/vhdl_libs/cyclonev vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] [[Synthese av VHDL - Oppdatert]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] [http://www.ashenden.com.au/ Ashenden Designs] [http://freerangefactory.org/books_tuts.html Free Range VHDL textbook] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] [http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [http://bitvis.no/products/bitvis-utility-library/ Bitvis utility library] [[Category:Mikroelektronikk]] 764fe168572d14320ed19f3dce6d98a04eac6cfe 2395 2388 2017-02-02T13:42:14Z Nfyku 4 wikitext text/x-wiki <!-- Mapping av alterabibliotek: <pre> vmap cyclonev /prog/altera/vhdl_libs/cyclonev vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> --> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] [[Synthese av VHDL - Oppdatert]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] [http://www.ashenden.com.au/ Ashenden Designs] [http://freerangefactory.org/books_tuts.html Free Range VHDL textbook] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] [http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [http://bitvis.no/products/bitvis-utility-library/ Bitvis utility library] [[Category:Mikroelektronikk]] 51a4cff4941ff6ac3f160de7f601e8e8796d3c78 6 484 2389 2226 2017-01-25T14:26:55Z Ogr043 86 Ogr043 uploaded a new version of [[File:1.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 569 2390 2017-01-25T14:28:27Z Ogr043 86 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 481 2391 2203 2017-01-25T14:28:52Z Ogr043 86 /* What's in the folders? */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wr, rd => sbi_if.rd, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} 1d24a0c9adf72906632d9e43cbbf475223693a0e 2412 2391 2017-02-17T15:20:10Z Oly004 94 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} 3e19de6589179a6aeef4bef6176b86477613ffef 0 25 2392 2140 2017-02-01T10:36:49Z Nfyku 4 wikitext text/x-wiki == Mikroelektronikk == * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim * [[Bitvis UVVM VHDL Verification Component Framework]] * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Cadence Virtuoso]] * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven * [[SmartFusion2]] Oppsett og design med SF2 * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus [[Category:Mikroelektronikk]] 387ebc7e18d1a561a272a2d9624cd60e709466a8 2393 2392 2017-02-01T10:45:17Z Nfyku 4 Omorganisering wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Annet === * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[Bitvis UVVM VHDL Verification Component Framework]] * [[FLTK GUI]] Graphical User Interface using FLTK * [[Tutorials]] Tutorials from the web * [[ADS]] Getting started with Agilent Advanced Design System * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[SmartFusion2]] Oppsett og design med SF2 * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus == Andre fagressurser og laboratorieveiledninger== * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort [[Category:Mikroelektronikk]] ed5bb0bb8cc7551e7bbfc355d626fa7e4fc47678 2394 2393 2017-02-01T10:54:32Z Nfyku 4 wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper == Andre fagressurser og laboratorieveiledninger== * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] e11106b3abb1eae9331422566e43ed540ec32de9 0 34 2396 2092 2017-02-02T13:45:57Z Nfyku 4 Oppdatert oppstartsinstruksjon wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. ssh -X mikroserver3 source /eda/mentor/2016-17/scripts/QUESTA-CORE-PRIME_10.5c-4_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] 249c4c695d423e9c23ebee2c1c43871dcd70cfb3 2397 2396 2017-02-03T07:46:45Z Nfyku 4 /* Starte Questa Sim */ wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. ssh -X mikroserver3 # eller mikroserver2 source /eda/mentor/2016-17/scripts/QUESTA-CORE-PRIME_10.5c-4_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden i eksempel 6.3 i kompendiet. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> [[Category:Mikroelektronikk]] 51a5c3658cdb0ae9faafb61226e47441421f2680 2398 2397 2017-02-09T15:47:59Z Nfyku 4 /* Signaler og variable */ wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. ssh -X mikroserver3 # eller mikroserver2 source /eda/mentor/2016-17/scripts/QUESTA-CORE-PRIME_10.5c-4_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid? <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process; END architecture difference; </pre> f52ed686a250020529379241711615ee9b4bb40c 0 234 2399 2376 2017-02-10T09:36:47Z Nfyst 67 /* Defended PhD theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. (can be found via 'Bibsys') === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] 3bba616b58d4233d97d5a1d4d1dd8d6486aab5ce 2419 2399 2017-06-19T14:27:51Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. (can be found via 'Bibsys') === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] 8564ba6c6b5a522542b09ea4c9604da1a642a6db 2422 2419 2017-07-25T13:30:01Z Nfyst 67 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. (can be found via 'Bibsys') === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] 52f54c92486a472f87a01c4195f8f00e1cfa98da 6 571 2402 2017-02-15T14:33:09Z Gge002 52 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 572 2403 2017-02-15T14:49:29Z Gge002 52 Created page with "=Strålevern= ==Førstegangsbrukere== ==Regler for bruk av strålingskilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] File:TableHeader.jpg|thum..." wikitext text/x-wiki =Strålevern= ==Førstegangsbrukere== ==Regler for bruk av strålingskilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] [[File:TableHeader.jpg|thumb|alt=Logbokformat|Fig. 2 Logbokformat]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Hierarket er som i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab kildeansvarlig deles kildene ut av STK. #Lab kildeansvarlig velges av brukerne til den labben, STK eller Instituttleder. #Hver lab skal ha logbok hvor bevegelsene av hver kilde som hører til denne laben skal registreres. Logboken skal ha formatet fra Fig. 2: #Den første siden i labboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Logboken skal være på labben til enhver tid, bindet med tråd til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab kildeansvarlig ofte og uten varsel. #Det blir 1 nøkler til tilsvarende kildeskap med lab kildeansvarlig og 1 nøkkel med STK. Leder Teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er til stedet. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av overnevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine men overføringen skal skje med overtagelsesprotokoll som er en del av logboken. Lab kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab kildeansvarlig. Hvis han/hun ikke er til stedet kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over hodet på noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålingskilde skal markeres med skilt og eksponeringsvurdering skal utføres. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålingskilder uten dosimeter. STK og HMS ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetrer til HMS ansvarlig i øyeblikket de finner ut at de er gravide (se punkt 18). Dosimetrene blir returnert etter fødsel om fremdeles ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. 87e14d425c283ef4df9ac0d8740b0034bcd1d022 2404 2403 2017-02-15T15:02:31Z Nfyku 4 Korrektur wikitext text/x-wiki ==Førstegangsbrukere== Her kommer tekst ==Regler for bruk av strålingskilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] [[File:TableHeader.jpg|thumb|alt=Logbokformat|Fig. 2 Logbokformat]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bindet med tråd til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt og eksponeringsvurdering skal utføres. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. c9a301287975bd1c24e687efa165d01340217ea2 2406 2404 2017-02-16T08:22:50Z Gge002 52 wikitext text/x-wiki ==Førstegangsbrukere== Førstegangsbrukere skall: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålingskilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke ha dosimeter i løpet av graviditeten) ==Regler for bruk av strålingskilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] [[File:TableHeader.jpg|thumb|alt=Logbokformat|Fig. 2 Logbokformat]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bindet med tråd til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt og eksponeringsvurdering skal utføres. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. 26c0fa721e921fdc087e8e07a150464107476877 2407 2406 2017-02-16T08:26:12Z Nfyku 4 Korrektur wikitext text/x-wiki ==Førstegangsbrukere== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke ha dosimeter i løpet av svangerskapet) ==Regler for bruk av strålekilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] [[File:TableHeader.jpg|thumb|alt=Logbokformat|Fig. 2 Logbokformat]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt og eksponeringsvurdering skal utføres. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. b6067b1b48b0c6384761020f2ce72febac87724f 2410 2407 2017-02-16T08:35:54Z Gge002 52 wikitext text/x-wiki ==Førstegangsbrukere== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke ha dosimeter i løpet av svangerskapet) ==Regler for bruk av strålekilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] [[File:TableHeader.jpg|thumb|alt=Logbokformat|Fig. 2 Logbokformat]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. 3a69d6484d40c2ad29362fabbc1f78ecbee16b63 2411 2410 2017-02-16T17:03:20Z Gge002 52 wikitext text/x-wiki ==Førstegangsbrukere== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ==Regler for bruk av strålekilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] [[File:TableHeader.jpg|thumb|alt=Logbokformat|Fig. 2 Logbokformat]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. f556b46f10971944995ab45727e984ae8747fa2d 0 154 2405 2124 2017-02-16T08:07:33Z Nfyku 4 wikitext text/x-wiki IFTs wiki er i utgangspunktet<ref name="lesbar">Det går an å stenge enkelte sider slik at kun brukere ved UiB får tilgang</ref> lesbar for alle som ønsker det, men det kreves såkalte sysops-rettigheter for å kunne opprette eller redigere sider. Noen brukere (Bureaucrats) kan gi slike rettigheter. Ta kontakt med en av dem hvis du trenger editeringsrettigheter. Husk å logge inn før du spør om slike rettigheter. * [http://www.uib.no/personer/Kjetil.Heitmann Kjetil Heitmann] * [http://www.uib.no/personer/Kjetil.Ullaland Kjetil Ullaland] ---- <references/> 841863d031f1d56476e56352287c19fa61052aeb 6 573 2408 2017-02-16T08:29:57Z Gge002 52 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 574 2409 2017-02-16T08:29:57Z Gge002 52 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 472 2413 2371 2017-04-05T08:05:30Z Nfyku 4 Changed cadence init wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. First chose a parent directory, e.g. cd ~/ihp Copy the user environment design and set general Cadence environment variables by doing: cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/work/skel . source /eda/cadence/2016-17/scripts/analog_flow.sh Change sh.cadence in ~/ihp/skel/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment source ~/ihp/skel/cds/sh.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] fc7f1e33976f019ffc1064e11aff88728bd08fe6 2414 2413 2017-04-05T08:30:11Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. Copy the user environment design to your chosen parent directory (e.g ~/ihp) and set general Cadence environment variables by doing: cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/work/skel ~/ihp source /eda/cadence/2016-17/scripts/analog_flow.sh Change sh.cadence in ~/ihp/skel/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment source ~/ihp/skel/cds/sh.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] ca0a1922f0a7338138292f06a5d6ecabd85b19a5 2415 2414 2017-04-20T15:01:15Z Nfyku 4 Updated designkit to .5.0_a wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. Copy the user environment design to your chosen parent directory (e.g ~/ihp) and set general Cadence environment variables by doing: cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp source /eda/cadence/2016-17/scripts/analog_flow.sh Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment cd ~/ihp/cds/ source sh.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] 6d90949fc9e71ad2e3faea657fb6ea150f913b4a 2416 2415 2017-04-21T11:30:36Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The first time you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2016-17/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence Start the design environment by: virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] 23831dedde0ec20270f3362cc8b8068827b82196 2417 2416 2017-04-27T12:38:46Z Fli091 93 Made all the commands copy-and-pasteable wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The first time you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2016-17/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence virtuoso & Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] 0a92ed7b4dde02a3b4077c88f1392efafe3add9e 2426 2417 2017-09-15T11:28:29Z Fli091 93 bash alias for starting virutoso wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2016-17/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To create a command that will do this for you try this command: echo "alias startVirtuoso='source /eda/cadence/2016-17/scripts/analog_flow.sh && cd ~/ihp/cds/ && source sh.cadence && virtuoso &'" >> ~/.bashrc Typing 'startVirtuoso' in the terminal will execute these four commands Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] 768447b67fb4af9d5382d068492f133ba458f535 0 278 2418 2225 2017-04-28T11:50:48Z Fli091 93 Flyttet øvingsoppgaver med IC studio til bunnen og endret overskrift til "gamle" wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Using Vivado ==== * [[Install Vivado 2015.4 with free licens]] * [[VGA controller VHDL code]] * [[Nexys4_Master.xdc]] * [[Using the VGA controller with block ram generator and clock wizard]] === Gamle øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] 594d9d1d532873a1524d3722f21278d6ca89bda5 6 575 2420 2017-06-19T14:28:30Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 467 2421 2088 2017-07-05T11:01:21Z Ave082 33 Replaced content with "== SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre>" wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> 908e5080acfa7fe32b0501e98f88fd8505480ca6 0 137 2423 2359 2017-08-20T19:05:48Z Nfyal 26 /* Particle Physics */ wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] f52806199fd54d14c43ff9b508753ff03911bd1a 6 576 2424 2017-08-20T19:06:12Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 160 2425 2344 2017-08-22T09:43:48Z Nfyal 26 /* Upcoming tutorials */ wikitext text/x-wiki == Previous tutorials == [[Mini parallab workshop, March 19, 2009]] [[Software workshop, 09/09-09]] [https://indico.cern.ch/event/524296/overview ATLAS software tutorial June 6-10, 2016 at CERN] [https://indico.cern.ch/event/472469/overview ATLAS analysis tutorial, 7-8 February 2016, Oslo ] [https://indico.cern.ch/event/465378/ ATLAS software tutorial ] [https://twiki.cern.ch/twiki/bin/view/AtlasComputing/ComputingTutorials ATLAS computing tutorials twiki] == Upcoming tutorials == [https://twiki.cern.ch/twiki/bin/view/AtlasComputing/SoftwareTutorial?redirectedfrom=AtlasComputing.RegularComputingTutorial Regular ATLAS Computing tutorials wiki] [https://atlasop.cern.ch/twiki/bin/view/Main/ShiftTraining Atlas Control Room Shifts Training] == Possible future tutorials == Some of these could be collected into a workshop in collaboration with Oslo and/or also ALICE. * C++ / ROOT ** Introduction C++ features and syntax for non-experts ** Common C++/ROOT problems and solutions ** A hands on tutorial on how to write a good class * ATHENA ** Running RecExCommon ** Implementing an algorithm ** Making a dual use tool (perhpas too in depth) * Mini Fimm tutorial 2 * Grid tutorial * Statistics / Data Analysis [[Category:Particle Physics]] e6c14d6477bfb7546c40d38ca2105765d77ccae5 0 461 2427 2370 2017-09-15T11:48:18Z Fli091 93 La til [[Category:Mikroelektronikk]] wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 source /eda/cadence/cadence_init.sh First time you should add the following line to your cds.lib file before starting the design environment. If the ~/cds.lib doesn't exist, just create it. DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf Virtuoso Mixed Signal Design Environment is started by issuing this command: tsmc_cds_start In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. # Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] # Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] d52ba9906fe36a26dabe43f97583661b45062b4c 0 460 2428 2037 2017-09-15T12:02:48Z Fli091 93 La til [[Category:Mikroelektronikk]] wikitext text/x-wiki =Cadence design with AMS 350nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs, choose direction and click on the schematic to place it. Create one input and one output. 7. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 8. To check and save the schematic, press 'x' or click the "Check and save" icon. 9. If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 10. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 10. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol- [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] 77d55b347493ded98714ad35095a6d3280b11b97 14 577 2429 2017-09-15T12:07:16Z Fli091 93 Created category:mikroelektronikk wikitext text/x-wiki This page lists all microelectronics-related pages on this wiki 595c70c11598ac2be935b02c865b785d37a4ca44 0 478 2430 2132 2017-09-15T12:09:33Z Fli091 93 La til [[Category:Mikroelektronikk]] wikitext text/x-wiki = Simulate with corner cases = To simulate with the corner cases in the fabrication process you have to add the corner files provided in the design kit. [[File:Selection_001.png|200px]] Choose "Click to add corner" "Click to add" the model files you need. Ex. The corner files for the MOS transistor in IHP130nm process is located in $IHP_TECH/tech/SG13_MOS/library/spectre/cornerMOSlv_psp.scs After adding the model files needed proceed by adding multiple corners: [[File:corner.png|400px]] The model files contains sections with the different corners. Choose sections and make sure you enable the section "tick box" and name the corner with a corresponding name: [[File:sections.png|400px]] The corners setup also makes it possible to simulate for different temperatures or design variables like VDD and transistor length. Ex. test for three different temperatures with comma as separation: -20,30,80 [[File:complete.png|400px]] [[Category:Mikroelektronikk]] 88475807ac85f18a872b99cc54d478f7a2000128 0 555 2431 2306 2017-09-15T12:09:43Z Fli091 93 La til [[Category:Mikroelektronikk]] wikitext text/x-wiki To create a butterfly curve, for example for characterizing SRAM read and hold margins, simulate a single DC sweep (one source, one sweep) on a input. Plot both the input (shows up as a straight line for a linear DC sweep) and the output (shows up as the DC response of your circuit). Have both plots in the same subwindows. go to Axis -> Y vs Y choose the first trace, press ok. go again to Axis -> Y vs Y choose the second trace, press ok. Put both results in the same plot, and you are finished. [[Category:Mikroelektronikk]] ad480252fbeeb787953569e7e78408673f5efe2e 0 295 2432 1229 2017-09-15T12:10:40Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so its listed wikitext text/x-wiki = Reworking = = Martin 09.6 XL machine = == Hardware == === Gas & power === * Open the valves on the Nitrogen bottle, the nitrogen line close to the bottle (red lever), and the nitrogen line close to the soldering machine (red lever). * Open the valve for the pressurized air behind the white wall cabinet (red lever). * Switch on the soldering machine: One switch located on the bottom unit of the soldering machine, on the behind side in the middle. One switch on the DBL (the control unit, on the behind side, a bit to the right. === Unterheater === === DBL === === Placement Arm === ==== Vacuum nozzles ==== ==== Hot air nozzles ==== ==== Lenses ==== === Handling tools === == Software - Easy older == === Desolder === he default profile is chosen with the hot air nozzle that you select. But for the desoldering, to create a profile, I would have a bit longer time for preheating and soldering, because you don't want to end up with a half desoldered BGA ;) The profiling will shorten the time, and we can't use the desoldered FPGA anyway, since we can't reball it. There are different profilers to create a BGA profile (rapid, classic, ...). I don't recall wich one it is, but there is one where it asks you to attach temperature probes to the top side of the BGA, and to the underside (as good as you can get it between the solderballs). You can use the teflon tape to attach the probes, but you should avoid air bubbles close to the probes under the tape. With one of the profilers you can then desolder the BGA, the profile goes through pre heating and soldering state, and there is a button "solder point" which is greyed out in the beginning. During the solder phase this button becomes clickable, and you should use the dentist tools to carefully try to lift the BGA from the board. When the solder is liquid and you can lift the BGA, then you should click "solder point" and take off the BGA. Then comes a cool down phase. Then you should have a customised profile for this BGA and board. ==== Rapid profiling ==== ==== Classic profiling ==== ==== Optimize profile ==== === Despense === If you are done with test runs of placing, and plan to solder, you can use the "Dispense" to apply flux to the board with the foot pedal and the with brush. === Auto Vision Placer === Before you need to choose the placement nozzle that will hold your BGA with a vacuum. It should be square about 1x1 cm for you BGA. Loosing the silver screw on the arm over the placement nozzle and disconnect the rubber tube. Start AVP and choose the lens that your BGA fits in. I think the one that fits for you is called 'Maxi BGA'. Then you mark the outline on the PCB, we got the best results with taking the inside edges of the solder placement marks, but in theory you can also take the lands itself. You need to mark two adjacent corners and the opposing edge. Since there is no mark for the edge, you can take the line from the solder placement marks as far to the inside as you can get. When you are happy with the drawn square, you can turn on the vacuum put the BGA on the tip of the placement nozzle. Then you click "nozzle down" and mark the outline of the BGA, again two corners and one edge. Because of the fuzzy corners where the BGAs where cut/broken off, you might have set the cursor that the corner fits to the clean cut edges. THen you can place the BGA, and check if it aligns correctly. === Solder === After the placing from above, you can select the solder part. Before starting the soldering, you should check that the hot air nozzle aligns properly with the BGA, and you might have to move the arm a bit manually to get it aligned (there is a switch to turn the magnet of on the base of the arm). Then you have to check the height, that the solder nozzle doesn't touch the PCB or the BGA. In order to not bend the placement arm, put your thumb under the placement arm, and push down the red part with your pointer. You can adjust the height with the screw on the top. There shouldn't be more then 1mm between the solder nozzle and the board. Then you can click "Solder" and it will ask you if the underheater support and nozzle is in place. This is the last chance to fix it. When you click next, the machine goes through the solder profile. After soldering you can save the report as pdf somewhere (print to pdf printer). === Clean Pad === With the clean pad function the underheater is on, and you can use the hot air pen from the stand next to the PC to clean the solder rests of the PCB, also using the suction pen from the stand. The lands can come off easily if you are not careful. But if you use a new board to solder, you don't need to do this. == ReBalling == The process of attaching new solderballs to a previously desoldered BGA is called reballing. For this we need a small reballing oven, into which the BGA goes, and a mask that corresponds to the ball layout on the BGA. [[User:Dfe002|Dominik]] 09:03, 26 March 2010 (UTC) [[Category:Mikroelektronikk]] 36e0070b49d80200428e1d7de9a60728bd4afab4 0 454 2433 2009 2017-09-15T12:10:58Z Fli091 93 Removed duplicate and triplicate [[Category:Mikroelektronikk]] wikitext text/x-wiki = Reflow Soldering = This tutorial explains the use of the Techno Print HA-02 reflow oven. A simple and practical step-through procedure is suggested to limit the effort for the first time user. The user manual for the oven can be downloaded from [[Media:Rfo-ha02-manual.pdf]], while a quick search on the web for "reflow soldering" should give some basic knowledge about reflow soldering. The oven should be placed inside a fume cupboard to draw unhealthy and annoying solder fumes away from the person soldering. == When to use it? == Do I really need this oven? Many components can easily be soldered by hand with better results. In general: if you can do it by hand, forget the oven. Some components do not have accessible pads, or they are simply too densely placed for hand soldering. This is when the oven comes in handy, although at the cost of some time and effort. Another example is when you repeat the same soldering process for several identical PCBs, as reflow soldering is a quite fast process once the time and temperature settings are known. == Step 1 - Creating a Time and Temperature Profile == The process of soldering is divided into two zones - "preheat" and "reflow". Time and temperature has to be specified for both these zones to obtain the desired thermal profile, and the settings will differ from PCB to PCB. Temperature can be monitored by attaching a thermocouple to the PCB with Kapton tape. The desired thermal profile is then iteratively found by running the reflow process on the unpopulated PCB several times while adjusting the time and temperature settings of the oven. [[File:Thermocouple.jpg|816px]] Figure 1: Thermocouple used for temperature measurements [[File:Recommended_solder_profile.png|816px]] Figure 2: Recommended solder profile for Hamamatsu MPPC (From Hamamatsu S10362-11 series datasheet) [[File:Meas_solder_profile.png|816px]] Figure 3: Measured solder profile during reflow soldering == Step 2 - Apply Solder Paste == When a reasonable thermal profile is found, the components are attached to the PCB by the use of solder paste. Solder paste can be applied from the dispenser by hand, and it is a good idea to try this a few times on an old PCB to get the right amount of paste. Avoid mixing different solder pastes, and remove any old solder tin from the PCB and the components before applying the paste. Then place the components. == Step 3 - Do it! == You are now ready to do the actual reflow process. Since you now are familiar with the thermocouple, it might be a good idea to attach it to the PCB while doing the actual reflow soldering. In this way you can document that you actually followed the thermal profile when doing the real thing. == Thermal Shielding == If you have a PCB that is already populated, you might want to thermally shield some or all components. This can be done by wrapping the PCB in aluminum foil with a window where you want to solder. Pay attention to the thermal profile in your window, since the foil will make it harder to heat the PCB. [[File:Reflow_example.jpg|816px]] Figure 4: Example of reflow soldering of MPPCs with thermal shielding and monitoring [[Category:Mikroelektronikk]] 33ba53640a213af2ef32f7f160e521c6910bca93 0 37 2434 74 2017-09-15T12:11:23Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so its listed wikitext text/x-wiki =Laboratory exercise for building and running the HLT-RORC hardware/software= ==Simulation in ModelSim== 1. Extract "HLT-RORC.ZIP", file:/heim/torheim/arkiv/HLT-RORC.ZIP into your working directory. 2. Set environment variable PROJECT_PATH equal to /my_working_directory/HLT-RORC/modelsim. 3. Start modelsim, then open project file HLT-prosjektfil.mpf in directory HLT-RORC/modelsim. 4. Map the simulation libraries. You can do this by typing from the command line (in the following order): <PRE> vlib work # Creating the work library vmap altera_pci /pakke/mgc/altera/vhdl/altera_pci vmap lpm /pakke/mgc/altera/vhdl/220model vmap altera_mf /pakke/mgc/altera/vhdl/altera_mf </PRE> If the compiled simulation libraries have become obsolete, you will have to compile the libraries yourself. This can be done by typing (in the following order): <PRE> vcom &#8211;work altera_mf altera_mf_components.vhd vcom &#8211;work altera_mf altera_mf.vhd vcom &#8211;work lpm 220pack.vhd vcom &#8211;work lpm 220model.vhd </PRE> 5. The mstr_tranx.vhd module contains the master transactions controlling the simulation scenario. To run the simulation with interrupt transfers, set the variable int_or_not equal to 1. To run the simulation with DMA transfers only, set the variable to zero. 6.Now you should compile your testbench with the design into your library work. The testbench could then be loaded by typing <i>vsim -t ps work.testbench</i> from the !ModelSim command line (not specifying the resolution in ps will result in a a fatal error). To run the simulation with 32 bit PCI bus, you could simply type <i>force -freeze /testbench/ack64n 1</i> before running simulation. 7. Run the simulation by typing <i>run ![time in ns]</i>. (You can get rid of all the warnings if you choose <i>Simulate -> Simulation Options -> Assertions -> Ignore assertions for warning</i> from the menu line) ==Synthesizing, technology mapping and transferring the design onto the APEX20KE FPGA== 1. Open Precision RTL Synthesis. Choose <i>File -> New Project</i>. Set the working directory to whatever you want to. 2. Add all the required VHDL files to you project. Make sure local_side.vhd is the last added file (The last added file will automatically be set as top of design). 3. Choose Setup Design to set the following options: APEX 20KE as technology, EP20K400EFC672 as device and -2X for the speed grade. The design frequency shold be 40 !MHz. 4. Click Compile, followed by Synthesize. 5. Close Precision RTL Synthesis. Make sure to anser "Yes" when asked about saving the current implementation. 6. A subdirectory called local_side_impl_1 has now been created in your working directory. Copy the content of local_side_impl_1 to /your_working_directory/HLT-RORC/LS/run_1. Answer yes when questioned to overwrite existing data. 7. Open top_module.qpf from Quartus. Convert the project file to the new Quartus file format if asked to do so. 8. If necessary, choose Tools -> !SignalTap Logic Analyzer and update the SignalTap file to the new file format. 9.Choose Assigments -> Settings -> User Library and add the correct library path (your_working_directory\HLT-RORC\pci_compiler-v2.1.1\lib). The newer versions of the pci core cannot be used, since the APEX20KE has been abandoned from further development. 10. Choose <i>Processing -> Start Compilation</i> to compile the design (this will take some time). 11. Choose <i>Tools -> Programmer</i>. Now choose JTAG as MODE. To make your programming file come through the scan chain, you have to add the device EPM7256B. The EPM device has to be the first on the list. 12. From the file menu you can now choose <i>Create/update -> Create JAM, SVF or ISC file</i>. 13. SSH to pc-rcu.fi.uib.no. Enter the directory where the .jam file has been saved (should be /your_working_directory/HLT-RORC/Quartus) 14. type <i>jamplayer -p378 -aCONFIGURE top_module.jam</i>. In case you receive the following error message: "Error: can't open file "/heim/torheim/rorctest/HLT-RORC/Quartus/top_module.jam", ensure that you have set the correct user privileges for HLT-RORC directory including its files and folders. You can do this by typing chmod -R 666 HLT-RORC. 15. Reboot your system. The HLT-RORC should now be ready and running. On pc-rcu.fi.uib.no, BAR0 will probably be mapped to FB400000. This can be checked by typing <i>/sbin/lspci -v</i> from the command line. ==Verifying the implementation with the Vanguard Logic Analyzer== 1. Start the Analyzer (BusView.exe) 2. Choose <i>File -> New -> Analyzer Setup</i> 3. Add this event: PCI0 in transfer mode with address FD0xxxxx. 4. Add this trigger: <PRE> Samling in TRANSFER mode Store (ALL) If (PCI0) then Trigger at 50% of trace Endif </PRE> 5. Cut and paste this text into an empty text file and save the file as testbench.scr: <PRE> f FB400000 FB400000 FD000000 f FB400004 FB400004 00000400 f FB400008 FB400008 FD000000 f FB40002C FB40002C FD000000 f FB400030 FB400030 FD000000 f FB400018 FB400018 00000011 f FB400020 FB400020 00000019 f FB400024 FB400024 00000001 f FB400024 FB400024 00000000 f FB400028 FB400028 AFFED00F </PRE> NB! This script assumes that the base address for BAR0 in the HLT-RORC is FB400000. It also assumes that the PCI base address for the Vanguard local target memory is FD000000. 6. Choose <i>Exerciser -> Script -> Load</i> and enter testbench.scr. 7. Choose <i>Exerciser -> Target</i> and enable the local target memory. Check that the Memory Window Address is consistent with the memory addresses in the script file. 8. Enter F9 to start sampling on the PCI bus. Then enter F10 to run the exerciser script. The exerciser script now runs the same scenario as in the VHDL testbench. If the HLT-RORC-4 design is working, the analyzer should be triggered by the HLT-RORC writing bursts of data words to the local memory. 9. Enter Alt-F9 to halt the analyser after the analyzer has been been triggered. Then choose Exerciser -> Local -> Display to examine the data written to local target memory by HLT-RORC. ==Verifying the implementation with the software== NB! Step 1-2 can only be done by a user with root permission. The first steps should therefore be taken care of by the supervisor, so the students doing this exercise can jump directly to point 4. 1. To run the software, a kernel module called psi has to be inserted into the kernel. The PSI tar.gz file can be downloaded from http://www.kip.uni-heidelberg.de/ti/HLT/software/software.html. If you download PSI version 0.8.2 from august 2003, you will have to patch psi_mod.c to make it compile on newer kernels. A patchfile called psi_mod.patch is located in the HLT-RORC directory. Before compiling, remember to change the TOPDIR variable in the Makefile and remove -DWITHBIGPHYS if bigphys is not compiled into the kernel (and it probably isn't). Now you can install the module by entering directory psi-0.8.2\src\driver.linux and typing (in the following sequence): <PRE> make clean make module make install make dev (or typing manually mknod /dev/psi c 100 0) chmod 666 /dev/psi (to give normal users permission to access the device file) </PRE> The module can now be installed by typing <i>insmod psi.o</i> (You will need root permissions to do this. If you want to use my precompiled binaries instead of compiling yourself, make sure to boot up the computer with the 2.4.20custum-bigphys kernel. You can check which kernel is running by typing 'uname -a'.) Make sure that you are running with the same kernel when loading the module as when compiling the module, unless the modules wont work. To compile the PSI API, go to directory psi-0.8.2\src\libpsi.linux and type <i>make</i>. 2. Enter directory HLT-RORC/src. If necessary, you will have to edit Makefile and Rules.make before compiling. Then run <i>make all</i> followed by <i>make install</i>, <i>mknod /dev/irqsignal c 120 1</i> and <i>chmod 666 /dev/irqsignal</i>. Now you can insert the irqsignal module by typing <i>insmod irqsignal major=120</i>. 3. Enter directory HLT-RORC/example. Compile the included files by typing make generate_irq. Remember to change the PSIDIR variable in the Makefile before compiling. 4. Run the compiled program generate_irq. The program will set up the HLT-RORC card to start interrupt-driven DMA-transfers. A signal handler located in the generate_irq program will respond to the interrupts. The program can be terminated by pressing Ctrl-C. 5. To observe the transactions with the Vanguard Analyzer, use the same events and trigger conditions that were shown in the previous example. [[Category:Mikroelektronikk]] 8d0073b8205b7e9993f2d8a215c7446cf4858dd9 0 416 2435 1980 2017-09-15T12:11:38Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so its listed wikitext text/x-wiki =Installation process= ==Download== Download from: http://www.actel.com/download/software/liberosoc/files.aspx?os=WIN ==Get a free 1 year license== Goto: http://www.actel.com/Portal/DPortal.aspx and choose "Libero Gold Node Locked for Windows" You need to register an account if you have not allready done so. ===Find out your Disk Serial Number=== Windows 8: 1. Open up a command prompt window by right clicking anywhere on the Start Screen and then click on "All apps". Scroll to the right until you find the "Windows System" section heading, and click on the "Command Prompt" tile. 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. Windows XP / Windows Vista / Windows 7: 1. Open up a command prompt window (Start Menu > All Programs > Accessories > Command Prompt). 2. Type in: vol. 3. The Volume Serial Number is the Disk Serial Number. It will take a couple of hours before the license arrives. ==Install== Start LiberoSoCv11 * Select Install Libero SoC (not the SA) * Select to install ALL ** Synplify Pro ** SoftConsole ** Synphony ** Identify ** ModelSim ** Fusion ** Igloo, Igloo nano ** Igloo Plus ** Iglooe ** ProAsic3 ** ProAsic3E ** ProAsic3L ** SmartFusion ** SmartFusion2 Apply and install license if you not already have a license installed. Start up Libero and select the tab marked "Catalog" in the bottom left. Press the button above saying to download new cores. =Tutorials= Programming of the SF2 takes a loooong time, even before the activity light starts to flash on the FlashPro4. Don't despair, the program is probably not crashed. The tutorials were made for an early version of Libero11, but the text has somewhat been updated to be in line with the release version of Libero11. In case of doubt, refer to the text and use common sense. Some of the demo C code has also changed. The tutorials are made for the SF2-STARTER-KIT-ES-2 which contains the BGA896 SF2 engineering sample (ES stamped on bottom left on chip). Newer starterkits may contain other devices and the device configuration would thus be different. The small white usb stick in the SF2 starter kit is a wifi device. Most of the "answers for questions" strongly depend on the chip and the version of the software and thus are not correct. For the tutorials using the rs232, don't use the reset button as it will garble the text. Relaunch the debugger instead. Don't use spaces in the path to were you keep the design files as Modelsim handles this badly. The tutorial files can be found on mikroserver1 in the folder /prog/cadence/SF2_tutorial Other designfiles and documents can be found here: http://emcraft.com/products/153 Add tips or corrections for tutorials below. ==Tutorial 1: SF2 fabric== ==Tutorial 2: SF2 ARM Cortex-M3 == ==Tutorial 2: SF2 USB== The mass storage test didn't work with a Sandisk cruizer 4GB micro. =Use of Questasim with SF2 cores= * Rightclick in the library pan of Questasim and choose new->Library. * Choose "A map to an existing library". * Set Library name to "SmartFusion2" and path to "c:/Microsemi/Libero_v11.1/Designer/lib/modelsim/precompiled/vhdl/SmartFusion2" or correct it to the place where you installed libero. * Include the library in the files where you need SF2 cores The same applies for other actel devices. =Libero errors, warnings and problems= * If you get "Warning: CMP008: module_name is not an Actel cell defined in the cell library." it means the mentioned module was not included in the synthesis and thus assumed to be an Actel standard module. Rightclick synthesis and select "Organize input files->Organize source files" select the mentioned module and press add. * Generate programming data fails without explanation: Constraint format has changed between Libero versions. Generate a new constraint file using the I/O editor based on the data in the old constraint file. * When a project is opened, if there is a message saying that the project is already open in another instance of Libero, go to the folder ''tooldata'' in the project directory and delete a file called ''libero.xyzv''. Where xyzv is some four digit number. [[Category:Mikroelektronikk]] fb8dea9674c0df31017204cfb59fb5458b63db6c 0 410 2436 2094 2017-09-15T12:14:16Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so its listed. Removed invalid category wikitext text/x-wiki == XJDeveloper == Dette er ei innføring i XJDeveloper. Tilhøyrande dokumentasjon er meint brukt til XJDemo Board versjon 1.2. === Dokumentasjonsmappa === Dokumentasjonsmpappa inneheld: * Krinsskjema * Bilete av demokort v.1.2. * Demokort-netliste * Diverse test-filer * Device-filer === Sette opp kortet === Det fyrste som gjerast er å kople demokortet til datamaskina gjennom XJ Link. Bruk ein av USB-inngongane på baksida av maskina. Deretter må det lagast ei prosjektmappe, som skal innehalde alle filene som vert laga. Mappe-plasseringa speler inga rolle. For å starte XJDeveloper: start>Programs>XJTAG 2.4>XJDeveloper. Lag eit nytt prosjekt, og lagre det i prosjektmappa. Gje prosjektet namnet "demo". Når dette er gjort, dukker dialogboksen "Add board" automatisk opp. I denne boksen gjev du kortet namn, og du gjev XJDeveloper netlista til demokortet. Gje kortet namnet "XJDemo". Netlista finn du i dokumentasjonsmappa - demo.net I tillegg har vi ei BOM-fil, som gjev XJDeveloper tilleggsinformasjon om komponentane på kortet. Denne fila er ikkje strengt naudsynt, men er nyttig. I dokumentasjonen finn du BOM-fila - demo.bom Legg til BOM-fila under BOM-settings. Etter å ha trykka next, set du tredje kolonne til å vere "Device Reference", fjerne kolonne "Value", og siste kolonne til "Device Description". Save. Under Power/Ground Nets i Setup-menyen i venstre marg er det to nett, 3.3V og GND. Dra desse to neta over i riktig kolonne til høgre. No veit XJTAG kva nett som er power og jord, og vil ikkje forsøke å skrive til desse. ==== Identifisere komponentane ==== Neste steg er å identifisere JTAG-kjeden. Trykk på add i Chain Setup. Til høgre for TDI, trykker du på select og vel CN1, pin 5. Trykk OK. Så kjem IC2.B3 opp i Select Next Pin-vinduet. Dra denne ned i JTAG Devices-lista. Trykk på Browse, og velg fila med same namn som IC2, altså XC9536XL_cs48.bsd Gjer det same med IC3.1, 3032at44.bsd. Begge desse filene finst i dokumentasjonsmappa. Neste steget er ein resistor, R49. Dra denne ned i JTAG-Devices-lista, men velg Connect device i den øvste fana. Så vel du Create file. Namngje fila Resistor, og connect 1 til 2. Til slutt kjem IC1.13. Høgreklikk og set denne til TDO. Save. No har vi etablert JTAG-kjeden. Deretter skal vi kategorisere non-JTAG-devices. Under Categorise Devices-fana i venstremargen, finn vi alle komponentane(devices), og ingen er endå kategoriserte. * Risistorane som er markerte med "Suggested Series Resistors" kategoriserer vi som passive komponentar. Dra alle over i "Passive", og velg Resistor.pdd som allereie er laga. * Alle jumperane på krinsen lar vi og vere passive. Gje jumperane[1,2,3,5,6] namn [jumper1,jumper2,...,jumper6] når vi lager filer til desse. For jumper[1,2,3] ser vi frå krinsteikninga at desse er meint kopla. Kople difor pinane 1-2,3-4,5-6,7-8 for desse tre jumperane. Jumper5 og jumper6 skal vere opne. * Alle pull-resistorane kategoriserer vi óg som passive. Når vi skal lage PDD-filer for desse, gjer vi som ved serie-motstanden, bortsett frå at vi skiftar frå Connect->Pull. Connect 1-2. ** No er det dukka opp ein siste resistor, R26. Legg denne til i resistor.pdd. * Under Ignore Devices legg vi kondensatorane, connectorane og "Other Resistors". I tillegg legg vi Switch1 under ignore(denne kjem vi attende til). * Under Test Devices legg vi til IC4,IC5, alle diodane, SW2 og SW3. IC4 gjev vi namnet EEPROM, IC5 gjev vi namnet SRAM, diodane gjev vi namnet LED, SW2 gjev vi namnet pushbutton1 og SW3 gjev vi namnet pushbutton2. * Under Logic Devices legg vi IC1. Frå krinsteikninga finn vi kva komponent IC1 er, og gjev XJDeveloper informasjon om det. Det neste steget er å identifiserer tilkoplingspinnane. Under Pin Mapping ser vi JTAG connectoren. Frå krinsteikninga finn vi korleis denne skal bestemmast(CN1). Dei pinnane som ikkje er gjevne namn i krinsteikninga, lar vi vere "input". === Testing === Det siste steget er å klargjere for test. Under Run and Deploy, finn ein fana XJRunnet Setup. Velg New>Add Global Function>CONNTEST. Gje testen eit fornuftig namn. Save. For å køyre testane som er sett opp under XJRunner-fana, trykk på Run Test-fana, og køyr testen. Når vi tester, ser vi at vi får opp ein short mellom to "created" net på IC2. Desse to neta finst på krinsen, men er ikkje med i netlista. For å be XJDeveloper sjå vekk i frå denne feilen, kople dei to neta saman. Det kan gjerast under fana Connections i venstremargen. Trykk på Add, velg Pin to Pin, og kople dei to neta saman. For å komme unna problemet med at GP1 er stuck at 1/0, går vi inn på Constant Pins-fana og set denne pinen til anten High/Low. Hugs å fysisk sett brytaren SW1 anten High/Low. Viss alt er sett riktig opp, skal vi ikkje lenger få feilmeldingar når vi køyrer testen. For å gje oss høve til å lage feil, er kortet utstyrt med jumperar. Sjå på krinsteikninga, og lag stuck at 0/1, kortslutningsfeil og brotfeil. ==== Minnetest(SRAM) ==== XJDeveloper har laga ei fil SRAM.xje frå informasjonen vi har gjeve programmet. For å kunne bruke ein ferdiglaga, enkel minnestest, modifiserer vi denne fila til å passe med testen. I dokumentasjonsmappa finn du fila SRAM.txt. Erstatt innhaldet i SRAM.xje med SRAM.txt. Den første, og enkle, minnetesten, ligg lagra i dokumentasjonsmappa - SRAM_test.txt. Kopier innhaldet i denne fila, og lim det inn Test Editor. Test Editor er eit av vindauga under Test Device Files-fana i venstremargen. Save. Lag så ein ny test i XJRunner-fana. Velg Add Device Function>IC5>Test. Gje testen eit fornuftig namn. XJTAG har vedlagt demokortdokumentasjonen gjeve oss ein meir utfyllande minnetest. Denne er vedlagt i dokumentasjonsmappa, og heiter memtestSRAM.xje. For å bruke denne, høgreklikker vi på IC5 i Categorised Devices>Configure>Other Device File>SRAM_SOP24.xje. Dette legg automatisk memtestSRAM.xje til som tilleggskode. No kan testen køyrast på nytt. Bruk jumperane kring minnekrinsen til å lage feil. ==== Flash-test ==== Hvis du får opp følgende feilmelding under kjøring av flash-test: <span style="color:red"> memtestFlash.xje(148): Zero is an invalid argument to LOG. IC3.TestDestructive failed >>>> FAILED <<<< </span> Er dette fordi initialiseringsfunksjonen ''Init();'' ikke er inkludert i "Test Destructive"-funksjonen. Dette kan fikses ved å legge inn ''Init();'' manuelt i filen ''AMD_Flash.xje'', som du finner i XJDeveloper: Velg Test Device Files (Under fanen ''Setup'', til høyre i XJDeveloper) -> AMD Flash 48-Pin TSOP 4Mb x8.xje (Under fanen ''Navigator'') -> AMD_Flash.xje Bruk ctrl+F for søk og skriv inn "TestDestructive()". Skriv inn ''Init();'' rett under linjen ''result := RESULT_PASS'', og trykk lagre. For å gjennomføre Non-Destructive test må dette også gjøres i "TestNonDestructive()"-funksjonen i samme fil. ==== EEPROM-test ==== Vedlagt i dokumentasjonen er fila 24LC23A.xje. Dette er testfila til IC4 - EEPROM. Kopier innhaldet i 24LC23A.xje inn i "Test Editor" under EEPROM i venstremargs-fana Test Device Files. Save. Då får ein to feilmeldingar, fordi funksjonane testen refererer til manglar. Desse finst i IIC.xje, som òg ligg i dokumentasjonen. Under Additional Code Files legg du IIC.xje til EEPROM. Save. På same måte som for SRAM-testen, må vi lage ein EEPROM-test under XJRunner-fana. No kan du køyre testen på nytt. ---- Lagt til forklaring på feil i flash-test og forslag til retting [[Category:Mikroelektronikk]] cb1e7b39e5acfdfb4d5e487d3ecadc2d91ba699a 0 415 2437 2103 2017-09-15T12:15:10Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so its listed wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths){{-}} Run "source europractice_installer.sh" and wait until done.{{-}} Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang="tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </source> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh ln -s /prog/cadence/cadence_$YEAR\_init.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh *sysstat [[Category:Mikroelektronikk]] 0f6e5b35d80260f6360335b7bf79a1c94eed281b 2440 2437 2017-09-15T12:31:18Z Fli091 93 Fli091 moved page [[Cadence]] to [[Cadence Virtuoso setup]]: Two pages named cadence on this wiki. Giving them explisit names wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths){{-}} Run "source europractice_installer.sh" and wait until done.{{-}} Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang="tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </source> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh ln -s /prog/cadence/cadence_$YEAR\_init.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh *sysstat [[Category:Mikroelektronikk]] 0f6e5b35d80260f6360335b7bf79a1c94eed281b 0 568 2438 2387 2017-09-15T12:15:36Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so its listed wikitext text/x-wiki == Software repository == We use the '''gitlab''' server hosted by IT of University of Bergen. Further information: * [https://docs.gitlab.com/ce/gitlab-basics/README.html Gitlab basics] * [https://docs.gitlab.com/ee/workflow/README.html Gitlab workflow] == Development workflow == Every logged-in user can access the main repository, however only a small group of administrators has write access. To contribute, a user creates a ''fork'' from the repository. This is a copy where a single developer or a group of developers have full access. The main repository has the following branches: * '''production''': the latest production code, in this branch we have release tags * '''master''': the latest stable release * '''dev''': the development branch In addition to those main branches there can be ''feature'' branches where development happens detached from the main branches. A ''feature'' branch is based on the ''dev'' branch and has a limited lifetime. === Creating a project fork === A ''project fork'' or ''repository fork'' is a copy of the original repository where a user or a group of users has/have full control. All development in our project is carried out in the individual forks. Branches of project forks are merged back into the main repository by '''merge requests''', preferably via '''fast forward''' merges. That requires developers to rebase project forks to the main repository and resolve all conflicts before requesting a merge. [https://docs.gitlab.com/ce/gitlab-basics/fork-project.html How to fork a project] Your repository fork is your sandbox, you can do whatever you want. Unless you have your own rules at hand right now you can apply the following: * leave the ''master'' branch in sync with the main repository, do not make commits to it * commit your changes to the ''dev'' branch * if you start a new feature, and it's expected to take a while, make a ''feature'' branch, e.g. ''dev-feature'' and give the feature a name * synchronize regularly to the main repository by rebasing === Making local development copy === Clone directly from your development fork, replace ''user'' appropriately. '''Note''': the gitlab offers two modes for the link to be cloned, you can choose ''ssh'' (default setting) or ''https''. If you can not clone with the proposed default link, try option ''https://''. git clone https://user@gitlab.uib.no/asim/asdc.git This repository will get the name ''origin'' in your local clone. If you have cloned already from the main repository, the upstream link can be changed as follows cd <reponame> git remote set-url origin https://user@gitlab.uib.no/asim/asdc.git === Pushing to development fork === Once you have added commits to e.g. the '''dev''' branch, those commits can be ''pushed'' upstream to the fork. git push origin dev === Pull/Merge request === All updates to the main repository are made via ''merge requests'' (github refers to them as ''pull requests''). A merge request requires the code update to be in a mergable branch in a development fork. Merge request are also used widely to share ''work-in-progress'' with your colleagues and for code reviews. Mark such Merge request with "'''WIP:'''". ==== Preparation ==== In order to avoid conflicts, first the fork has to be updated to the main repository. The idea behind this is that all potential conflicts can be resolved by the developer with the best knowledge about the matter, while the maintainer can simple merge ''fast-forward''. ==== Example workflow for a Merge request ==== # Go to your gitlab user space at [https://gitlab.uib.no/user https://gitlab.uib.no/user] (replace ''user'' appropriately. # Find the project fork, e.g. in the list of projects associated with you from the upper main menu. # In the line with the many columns regarding the repository, click on the "+"-symbol on the right hand side and choose "New merge request" # Select project and branch for both source and target, and click "Compare branches and continue" # Review the list of commits in this merge request, give it a descriptive title and description, pick an assignee # Submit the merge request === Importing an external package === The project will use a couple of external packages which are hosted in a different master repository. Copies of such external packages can be added to the gitlab server under our project group to provide a consistent package. Here is a proposed workflow for importing a package which is already hosted in git. # Create new repository in the asim group or ask for creation, lets call it ''newPackage'' # Fork the repository to your user space # Clone the package you want to import #:<pre> git clone <some_external_link> newPackage # we give it the new name</pre> #:<pre> cd newPackage</pre> # Redirect upstream URL to the fork in your gitlab user space #:<pre> git remote set-url origin https://user@gitlab.uib.no/user/newPackage.git</pre> # Now make a forced push (option ''-f'') to import the repository to your fork #:<pre> git push -f origin</pre> # Create merge request to branch ''import'' (if not existing, ''master'' or any other appropriate branch) by following the instructions [[Documentation#Pull/Merge request | Pull/Merge request]] [[Category:Mikroelektronikk]] 4990229e02bbdc29b64a035179bc32894738e50f 0 481 2439 2412 2017-09-15T12:16:22Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so its listed wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [http://bitvis.no/products/uvvm-vvc-framework/ Bitvis web page]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wr <= '0'; sbi_if.rd <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] 228ff7db36acbd0ed60c578d2feeafc5296ab8ab 0 578 2441 2017-09-15T12:31:19Z Fli091 93 Fli091 moved page [[Cadence]] to [[Cadence Virtuoso setup]]: Two pages named cadence on this wiki. Giving them explisit names wikitext text/x-wiki #REDIRECT [[Cadence Virtuoso setup]] aced73ef573ce9e5a0a92a33de531f54af852805 0 38 2442 2307 2017-09-15T12:32:10Z Fli091 93 Fli091 moved page [[Cadence Virtuoso]] to [[Cadence Virtuoso overview]]: Two pages named cadence on this wiki. Giving them explisit names wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] 363f9e5f66a2697461289d792300bf9b6ec9540f 0 579 2443 2017-09-15T12:32:10Z Fli091 93 Fli091 moved page [[Cadence Virtuoso]] to [[Cadence Virtuoso overview]]: Two pages named cadence on this wiki. Giving them explisit names wikitext text/x-wiki #REDIRECT [[Cadence Virtuoso overview]] 1a98d0ae6a1dd0d03a1807d45de75e69a0fb33ad 10 580 2445 2444 2017-09-15T13:04:09Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <includeonly>{{#invoke:Navbox|navbox}}</includeonly><noinclude> {{Documentation}} </noinclude> fe9b964401f895918ee4fe078678f1722a3c41ec 10 581 2447 2446 2017-09-15T13:04:09Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <div style="clear:{{{1|both}}};"></div><noinclude> {{documentation}} </noinclude> 38bab3e3d7fbd3d6800d46556e60bc6bac494d72 10 582 2449 2448 2017-09-15T13:04:09Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{#invoke:documentation|main|_content={{ {{#invoke:documentation|contentTitle}}}}}}<noinclude> <!-- Categories go on the /doc subpage, and interwikis go on Wikidata. --> </noinclude> ce7fd93f18c46b4fa871bf679afd05cbda72d8c4 10 583 2451 2450 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <includeonly><!-- -->{{#ifeq:{{lc:{{SUBPAGENAME}}}} |{{{override|doc}}} | <!--(this template has been transcluded on a /doc or /{{{override}}} page)--> </includeonly><!-- -->{{#ifeq:{{{doc-notice|show}}} |show | {{Mbox | type = notice | style = margin-bottom:1.0em; | image = [[File:Edit-copy green.svg|40px|alt=|link=]] | text = '''This is a [[Wikipedia:Template documentation|documentation]] [[Wikipedia:Subpages|subpage]] for {{{1|[[:{{SUBJECTSPACE}}:{{BASEPAGENAME}}]]}}}'''.<br />It contains usage information, [[Wikipedia:Categorization|categories]] and other content that is not part of the original {{#if:{{{text2|}}} |{{{text2}}} |{{#if:{{{text1|}}} |{{{text1}}} |{{#ifeq:{{SUBJECTSPACE}} |{{ns:User}} |{{lc:{{SUBJECTSPACE}}}} template page |{{#if:{{SUBJECTSPACE}} |{{lc:{{SUBJECTSPACE}}}} page|article}}}}}}}}. }} }}<!-- -->{{DEFAULTSORT:{{{defaultsort|{{PAGENAME}}}}}}}<!-- -->{{#if:{{{inhibit|}}} |<!--(don't categorize)--> | <includeonly><!-- -->{{#ifexist:{{NAMESPACE}}:{{BASEPAGENAME}} | [[Category:{{#switch:{{SUBJECTSPACE}} |Template=Template |Module=Module |User=User |#default=Wikipedia}} documentation pages]] | [[Category:Documentation subpages without corresponding pages]] }}<!-- --></includeonly> }}<!-- (completing initial #ifeq: at start of template:) --><includeonly> | <!--(this template has not been transcluded on a /doc or /{{{override}}} page)--> }}<!-- --></includeonly><noinclude>{{Documentation}}</noinclude> a1dda2f5e5ddf9097546af5acd7a7bad14fdac9d 10 584 2453 2452 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{#if: {{Is subpage namespace | {{#if:{{{1|}}}|{{NAMESPACE:{{{1}}}}}|{{NAMESPACE}}}} }} | {{#if: {{#titleparts:{{#if:{{{1|}}}|{{{1}}}|{{FULLPAGENAME}}}}|-1}} | {{#titleparts:{{#if:{{{1|}}}|{{{1}}}|{{FULLPAGENAME}}}}|-1}} | {{#if:{{{1|}}}|{{{1}}}|{{FULLPAGENAME}}}} }} | {{#if:{{{1|}}}|{{{1}}}|{{FULLPAGENAME}}}} }}<noinclude> {{documentation}} </noinclude> 9eeb1b689ce36891a0eaa40ee74d8207a9c95e09 10 585 2455 2454 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <includeonly>{{#invoke:For|For}}</includeonly><noinclude> {{Documentation}} </noinclude> 3f70c0fa7cd736071e7c6e7dcd90ff3704df26bb 10 586 2457 2456 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <includeonly>{{#invoke:Hatnote|hatnote}}</includeonly><noinclude> {{documentation}} <!-- Categories go on the /doc subpage, and interwikis go on Wikidata. --> </noinclude> 4a1d1028d07c9056022807a96051e1c82cf2a1c7 10 587 2459 2458 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{ombox | type = content | image = [[File:Ambox warning orange.svg|40px|alt=Warning|link=]] | imageright = | text = '''This {{ #switch:{{NAMESPACE}} |Module=Lua module |#default=template }} is used on <span class="plainlinks">[https://tools.wmflabs.org/templatecount/index.php?lang=en&namespace={{NAMESPACENUMBER:{{FULLPAGENAME}}}}&name={{urlencode:{{ #switch: {{SUBPAGENAME}} | doc | sandbox = {{BASEPAGENAME}} | #default = {{PAGENAME}} }}}} {{#if:{{{1|}}}|{{formatnum:{{{1}}}}}|a very large number of}} pages]</span>.'''<br />To avoid large-scale disruption and unnecessary server load, any changes to this {{ #switch:{{NAMESPACE}} |Module=module |#default=template }} should first be tested in its [[{{ #switch: {{SUBPAGENAME}} | doc | sandbox = {{SUBJECTSPACE}}:{{BASEPAGENAME}} | #default = {{SUBJECTPAGENAME}} }}/sandbox|/sandbox]] or [[{{ #switch: {{SUBPAGENAME}} | doc | sandbox = {{SUBJECTSPACE}}:{{BASEPAGENAME}} | #default = {{SUBJECTPAGENAME}} }}/testcases|/testcases]] subpages{{ #switch:{{NAMESPACE}} |Module=. |#default=&#32;or in your own [[Wikipedia:Subpages#How to create user subpages|user subpage]]. }} The tested changes can then be added to this page in a single edit. Please consider discussing any changes {{#if:{{{2|}}}|at [[{{{2}}}]]|on the [[{{ #switch: {{SUBPAGENAME}} | doc | sandbox = {{TALKSPACE}}:{{BASEPAGENAME}} | #default = {{TALKPAGENAME}} }}|talk page]]}} before implementing them. }}<noinclude> {{Documentation}} <!-- Add categories to the /doc subpage; interwikis go to Wikidata, thank you! --> </noinclude> 8d595acf61df4b1c13b280d8bb1d7f971259c4ea 10 588 2461 2460 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki #REDIRECT [[Template:Ns has subpages]] 2399d659a817ec9b4df84fe4e556039d08e809a8 10 589 2463 2462 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <includeonly>{{#invoke:Lua banner|main}}</includeonly><noinclude> {{Lua|Module:Lua banner}} {{documentation}} <!-- Categories go on the /doc subpage and interwikis go on Wikidata. --> </noinclude> dba3962144dacd289dbc34f50fbe0a7bf6d7f2f7 10 590 2465 2464 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{#invoke:main|main}}<noinclude> {{documentation}} <!-- Categories go on the /doc subpage, and interwikis go on Wikidata. --> </noinclude> a7952a0ddabebcef9371e9783f0fed2425a59187 10 591 2467 2466 2017-09-15T13:04:10Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <includeonly>{{#invoke:Navbar|navbar}}</includeonly><noinclude> {{documentation}} </noinclude> 868e3566b7e8a9a5a7f3dac75cac429c47de10d3 10 592 2469 2468 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{documentation subpage}} <!-- Categories go where indicated at the bottom of this page, please; interwikis go to Wikidata (see also: [[Wikipedia:Wikidata]]). --> {{#ifeq:{{FULLPAGENAME}}|Template:Navbox|{{high-risk| 2450000+ }}}}<includeonly> {{lua|Module:Navbox}}{{Template display|nomobile}}</includeonly> {{Navbox suite}} {{for|vertically-aligned navigation|Template:Sidebar}} This template allows a [[Wikipedia:Navigation template|navigational template]] to be set up relatively quickly by supplying it with one or more lists of links. It comes equipped with default styles that should work for most navigational templates. Changing the default styles is possible, but not recommended. Using this template, or one of its "Navbox suite" sister templates, is highly recommended for standardization of navigational templates, and for ease of use. {{Navbox visibility}} == Usage == Please remove the parameters that are left blank. <pre style="overflow: auto;">{{Navbox | name = {{subst:PAGENAME}}{{subst:void|Don't change anything on this line. It will change itself when you save.}} | title = | listclass = hlist | state = {{{state|}}} | above = | image = | group1 = | list1 = | group2 = | list2 = | group3 = | list3 = <!-- ... --> | below = }} </pre> == Parameter list == {{{{PAGENAMETDOC}} | name = Navbox/doc | state = uncollapsed | title = {{{title}}} | above = {{{above}}} | image = {{{image}}} | group1 = {{{group1}}} | list1 = {{{list1}}} | group2 = {{{group2}}} | list2 = {{{list2}}} | list3 = {{{list3}}} ''without {{{group3}}}'' | group4 = {{{group4}}} | list4 = {{{list4}}} | below = {{{below}}} <br /> See alternate navbox formats under: [[#Layout of table|''Layout of table'']] }} The navbox uses lowercase parameter names, as shown in the box (''above''). The required ''name'' and ''title'' will create a one-line box if other parameters are omitted. Notice "group1" (etc.) is optional, as are sections named "above/below". {{clear}} The basic and most common parameters are as follows (see [[#Parameter descriptions|below]] for the full list): : <code>name</code> – the name of the template. : <code>title</code> – text in the title bar, such as: <nowiki>[[Widget stuff]]</nowiki>. : <code>listclass</code> – a CSS class for the list cells, usually <code>hlist</code> for horizontal lists. Alternatively, use bodyclass for the whole box. : <code>state</code> – controls when a navbox is expanded or collapsed. : <code>titlestyle</code> – a CSS style for the title-bar, such as: <code>background: gray;</code> : <code>groupstyle</code> – a CSS style for the group-cells, such as: <code>background: #eee;</code> : <code>above</code> – text to appear above the group/list section (could be a list of overall wikilinks). : <code>image</code> – an optional right-side image, coded as the whole image. Typically it is purely decorative, so it should be coded as <code><nowiki>[[File:</nowiki><var>XX</var><nowiki>.jpg|80px|link=|alt=]]</nowiki></code>. : <code>imageleft</code> – an optional left-side image (code the same as the "image" parameter). : <code>group_n</code> – the left-side text before list-n (if group-n omitted, list-n starts at left of box). : <code>list_n</code> – text listing wikilinks using a [[Help:Lists|wikilist]] format. : <code>below</code> – optional text to appear below the group/list section. == Parameter descriptions == The following is a complete list of parameters for using {{tl|Navbox}}. In most cases, the only required parameters are <code>name</code>, <code>title</code>, and <code>list1</code>, though [[Template:Navbox/doc#Child navboxes|child navboxes]] do not even require those to be set. {{tl|Navbox}} shares numerous common parameter names with its sister templates, {{tl|Navbox with columns}} and {{tl|Navbox with collapsible groups}}, for consistency and ease of use. Parameters marked with an asterisk (*) are common to all three master templates. === Setup parameters === :; ''name''* :: The name of the template, which is needed for the "V&nbsp;• T&nbsp;• E" ("View&nbsp;• Talk&nbsp;• Edit") links to work properly on all pages where the template is used. You can enter <code><nowiki>{{subst:PAGENAME}}</nowiki></code> for this value as a shortcut. The name parameter is only mandatory if a <code>title</code> is specified, and the <code>border</code> parameter is not set, and the <code>navbar</code> parameter is not used to disable the navbar. :; ''state''* <span style="font-weight:normal;">[<code>autocollapse, collapsed, expanded, plain, off</code>]</span> :* Defaults to <code>autocollapse</code>. A navbox with <code>autocollapse</code> will start out collapsed if there are two or more tables on the same page that use other collapsible tables. Otherwise, the navbox will be expanded. For the technically minded, see [[MediaWiki:Common.js]]. :* If set to <code>collapsed</code>, the navbox will always start out in a collapsed state. :* If set to <code>expanded</code>, the navbox will always start out in an expanded state. :* If set to <code>plain</code>, the navbox will always be expanded with no [hide] link on the right, and the title will remain centered (by using padding to offset the <small>V&nbsp;• T&nbsp;• E</small> links). :* If set to <code>off</code>, the navbox will always be expanded with no [hide] link on the right, but no padding will be used to keep the title centered. This is for advanced use only; the "plain" option should suffice for most applications where the [show]/[hide] button needs to be hidden. : To show the box when standalone (non-included) but then auto-hide contents when in an article, put "expanded" inside {{tag|noinclude|p}} tags. This setting will force the box visible when standalone (even when followed by other boxes), displaying "[hide]", but then it will auto-collapse the box when stacked inside an article: :: <code><nowiki>| state =&nbsp;</nowiki></code>{{tag|noinclude|content=expanded}} : Often times, editors will want a default initial state for a navbox, which may be overridden in an article. Here is the trick to do this: :* In your intermediate template, create a parameter also named "state" as a pass-through like this: :: <code><nowiki>| state = {{{state<includeonly>|your_desired_initial_state</includeonly>}}}</nowiki></code> :* The {{tag|includeonly|o}}<code>|</code> will make the template expanded when viewing the template page by itself. ::* Example 1: {{tl|Peso}} with ''autocollapse'' as the default initial state. [[Catalan peseta]] transcludes it and has only one navbox; thus, the peso navbox shows. [[Chilean peso]] has more than two navboxes; thus, the peso navbox collapses. ::* Example 2: {{tl|Historical currencies of Hungary}} with ''expanded'' as the default initial state, as such: :::<code><nowiki>| state = {{{state<includeonly>|expanded</includeonly>}}}</nowiki></code> :::All transcluding articles show the content by default, unless there is a hypothetical article that specifies <code><nowiki>{{templatename|state=collapsed}}</nowiki></code> when transcluding. ::* Example 3: {{tl|Tourism}} with ''collapsed'' as the default initial state, as such: :::<code><nowiki>| state = {{{state<includeonly>|collapsed</includeonly>}}}</nowiki></code> :::All transcluding articles will show the template as collapsed by default, but the template will still be uncollapsed when displayed on its own page. :* The template {{tl|Collapsible option}} explains how to use the <code>state</code> parameter. It can be added to a {{tag|noinclude|p}} section after the template definition or to the instructions on the {{tl|documentation subpage}}. :; ''navbar''* :: If set to <code>plain</code>, the <span style="font-size: 88%;">V&nbsp;• T&nbsp;• E</span> links on the left side of the titlebar will not be displayed, and padding will be automatically used to keep the title centered. Use <code>off</code> to remove the <span style="font-size: 88%;">V&nbsp;• T&nbsp;• E</span> links, but not apply padding (this is for advanced use only; the "plain" option should suffice for most applications where a navbar is not desired). It is highly recommended that one not hide the navbar, in order to make it easier for users to edit the template, and to keep a standard style across pages. :; ''border''* :: ''See later section on [[#Child navboxes|using navboxes within one another]] for examples and a more complete description.'' If set to <code>child</code> or <code>subgroup</code>, then the navbox can be used as a borderless child that fits snugly in another navbox. The border is hidden and there is no padding on the sides of the table, so it fits into the ''list'' area of its parent navbox. If set to <code>none</code>, then the border is hidden and padding is removed, and the navbox may be used as a child of another container (do not use the <code>none</code> option inside of another navbox; similarly, only use the <code>child</code>/<code>subgroup</code> option inside of another navbox). If set to anything else (default), then a regular navbox is displayed with a 1px border. An alternate way to specify the border to be a subgroup style is like this (i.e. use the first unnamed parameter instead of the named ''border'' parameter): ::: <code><nowiki>{{Navbox|child</nowiki></code> :::: <code>...</code> ::: <code><nowiki>}}</nowiki></code> === Cells === :; ''title''* :: Text that appears centered in the top row of the table. It is usually the template's topic, i.e. a succinct description of the body contents. This should be a single line, but if a second line is needed, use <code><nowiki>{{-}}</nowiki></code> to ensure proper centering. This parameter is technically not mandatory, but using {{tl|Navbox}} is rather pointless without a title. :; ''above''* :: A full-width cell displayed between the titlebar and first group/list, i.e. ''above'' the template's body (groups, lists and image). In a template without an image, ''above'' behaves in the same way as the ''list1'' parameter without the ''group1'' parameter. :; ''group_n''* :: (i.e. ''group1'', ''group2'', etc.) If specified, text appears in a header cell displayed to the left of ''list_n''. If omitted, ''list_n'' uses the full width of the table. :; ''list_n''* :: (i.e. ''list1'', ''list2'', etc.) The body of the template, usually a list of links. Format is inline, although the text can be entered on separate lines if the entire list is enclosed within <code><nowiki><div> </div></nowiki></code>. At least one ''list'' parameter is required; each additional ''list'' is displayed in a separate row of the table. Each ''list_n'' may be preceded by a corresponding ''group_n'' parameter, if provided (see below). ::Entries should be separated using a [[newline]] and an [[asterisk]] (*). If instead two asterisks are used, it provides [[Nesting (computing)|nesting]] within the previous entry by enclosing the entry with brackets. Increasing the number of asterisks used increases the number of brackets around entries. :; ''image''* :: An image to be displayed in a cell below the title and to the right of the body (the groups/lists). For the image to display properly, the ''list1'' parameter must be specified. The ''image'' parameter accepts standard wikicode for displaying an image, ''e.g.'': ::: <code><nowiki>[[File:</nowiki><var>XX</var><nowiki>.jpg|80px|link=|alt=]]</nowiki></code> ::: nb: including "|right" will produce the usual left margin to provide separation from the list items and [[Zebra striping (computer graphics)|zebra striping]]. :; ''imageleft''* :: An image to be displayed in a cell below the title and to the left of the body (lists). For the image to display properly, the ''list1'' parameter must be specified and no groups can be specified. It accepts the same sort of parameter that ''image'' accepts. :; ''below''* :: A full-width cell displayed ''below'' the template's body (groups, lists and image). In a template without an image, ''below'' behaves in the same way as the template's final ''list_n'' parameter without a ''group_n'' parameter. For an example of the ''below'' parameter in use, see {{oldid|Main Page|352612160|this}} version of {{tl|Lists of the provinces and territories of Canada}}. === Style parameters === Styles are generally advised against, to maintain consistency among templates and pages in Wikipedia; but the option to modify styles is given. :; ''bodystyle''* :: Specifies [[Cascading Style Sheets|CSS]] styles to apply to the template body. This option should be used sparingly as it can lead to visual inconsistencies. Examples: ::: <code>bodystyle = background: #''nnnnnn'';</code> ::: <code>bodystyle = width: ''N''&nbsp;[em/%/px or width: auto];</code> ::: <code>bodystyle = float: [''left/right/none''];</code> ::: <code>bodystyle = clear: [''right/left/both/none''];</code> :; ''basestyle''* :: CSS styles to apply to the ''title'', ''above'', ''below'', and ''group'' cells all at once. The styles are not applied to ''list'' cells. This is convenient for easily changing the basic color of the navbox without having to repeat the style specifications for the different parts of the navbox. Examples: ::: <code>basestyle = background: lightskyblue;</code> :; ''titlestyle''* :: [[Cascading Style Sheets|CSS]] styles to apply to ''title'', most often the titlebar's background color: ::: <code>titlestyle = background: ''#nnnnnn'';</code> ::: <code>titlestyle = background: ''name'';</code> ::: <code>titlestyle = background: none;</code> — for no background color :; ''groupstyle''* :: CSS styles to apply to the ''groupN'' cells. This option overrides any styles that are applied to the entire table. Examples: ::: <code>groupstyle = background: #''nnnnnn'';</code> ::: <code>groupstyle = text-align: [''left/center/right''];</code> ::: <code>groupstyle = vertical-align: [''top/middle/bottom''];</code> :; ''group_nstyle''* :: CSS styles to apply to a specific group, in addition to any styles specified by the ''groupstyle'' parameter. This parameter should only be used when absolutely necessary in order to maintain standardization and simplicity. Examples: ::: <code>group3style = background: red; color: white;</code> :; ''groupwidth'' :: A number and unit specifying a uniform width for the group cells, in cases where little content in the list cells may cause group cells to be too wide. No default. However, may be overridden by the ''group(n)style'' parameter. Examples: ::: <code>groupwidth = 9em</code> :; ''liststyle''* :: CSS styles to apply to all lists. Overruled by the ''oddstyle'' and ''evenstyle'' parameters (if specified) hereafter. When using backgound colors in the navbox, see the [[#Intricacies|note hereafter]]. :; ''list_nstyle''* :: CSS styles to apply to a specific list, in addition to any styles specified by the ''liststyle'' parameter. This parameter should only be used when absolutely necessary in order to maintain standardization and simplicity. Examples: ::: <code>list5style = background: #ddddff;</code> :; ''listpadding''* :: A number and unit specifying the padding in each ''list'' cell. The ''list'' cells come equipped with a default padding of 0.25em on the left and right, and 0 on the top and bottom. Due to complex technical reasons, simply setting "liststyle = padding: 0.5em;" (or any other padding setting) will not work. Examples: ::: <code>listpadding = 0.5em 0;</code> (sets 0.5em padding for the top/bottom, and 0 padding for the left/right.) ::: <code>listpadding = 0;</code> (removes all list padding.) :; ''oddstyle'' :; ''evenstyle'' :: Applies to odd/even list numbers. Overrules styles defined by ''liststyle''. The default behavior is to add striped colors (white and gray) to odd/even rows, respectively, in order to improve readability. These should not be changed except in extraordinary circumstances. :; ''evenodd'' <span style="font-weight: normal;"><code>[swap, even, odd, off]</code></span> :: If set to <code>swap</code>, then the automatic striping of even and odd rows is reversed. Normally, even rows get a light gray background for striping; when this parameter is used, the odd rows receive the gray striping instead of the even rows. Setting to <code>even</code> or <code>odd</code> sets all rows to have that striping color. Setting to <code>off</code> disables automatic row striping. This advanced parameter should only be used to fix problems when the navbox is being used as a child of another navbox and the stripes do not match up. Examples and a further description can be found in the section on child navboxes below. :; ''abovestyle''* :; ''belowstyle''* :: CSS styles to apply to the top cell (specified via the ''above'' parameter) and bottom cell (specified via the ''below'' parameter). Typically used to set background color or text alignment: ::: <code>abovestyle = background: #''nnnnnn'';</code> ::: <code>abovestyle = text-align: [''left/center/right''];</code> ::: <code>belowstyle = background: #''nnnnnn'';</code> ::: <code>belowstyle = text-align: [''left/center/right''];</code> :; ''imagestyle''* :; ''imageleftstyle''* :: CSS styles to apply to the cells where the image/imageleft sits. These styles should only be used in exceptional circumstances, usually to fix width problems if the width of groups is set and the width of the image cell grows too large. Examples: ::: <code>imagestyle = width:5em;</code> ===== Default styles ===== The style settings listed here are those that editors using the navbox change most often. The other more complex style settings were left out of this list to keep it simple. Most styles are set in [[MediaWiki:Common.css]]. : <code>bodystyle = background: #fdfdfd; width: 100%; vertical-align: middle;</code> : <code>titlestyle = background: #ccccff; padding-left: 1em; padding-right: 1em; text-align: center;</code> : <code>abovestyle = background: #ddddff; padding-left: 1em; padding-right: 1em; text-align: center;</code> : <code>belowstyle = background: #ddddff; padding-left: 1em; padding-right: 1em; text-align: center;</code> : <code>groupstyle = background: #ddddff; padding-left: 1em; padding-right: 1em; text-align: right;</code> : <code>liststyle = background: transparent; text-align: left/center;</code> : <code>oddstyle = background: transparent;</code> : <code>evenstyle = background: #f7f7f7;</code> Since ''liststyle'' and ''oddstyle'' are transparent, odd lists have the color of the ''bodystyle'', which defaults to #fdfdfd (white with a hint of gray). A list defaults to <code>text-align: left;</code> if it has a group, if not it defaults to <code>text-align: center;</code>. Since only ''bodystyle'' has a vertical-align all the others inherit its <code>vertical-align: middle;</code>. === Advanced parameters === :; ''bodyclass'' :; ''aboveclass'' :; ''groupclass'' :; ''listclass'' :; ''belowclass'' :: This enables attaching a CSS class to group or list cells. The most common use for ''listclass'' is to give it the <code>hlist</code> class that will cause lists to render horizontally. All these parameters accept the <code>hlist</code> class, but if more than one parameter is used for <code>hlist</code>, use {{para|bodyclass|hlist}} instead. :; ''titlegroup'' :: This puts a group in the title area, with the same default styles as ''group_n''. It should be used only in exceptional circumstances (usually advanced meta-templates) and its use requires some knowledge of the internal code of {{tl|Navbox}}; you should be ready to manually set up CSS styles to get everything to work properly if you wish to use it. If you think you have an application for this parameter, it might be best to change your mind, or consult the talk page first. :; ''titlegroupstyle'' :: The styles for the titlegroup cell. :; ''innerstyle'' :: A very advanced parameter to be used ''only'' for advanced meta-templates employing the navbox. Internally, the navbox uses an outer table to draw the border, and then an inner table for everything else (title/above/groups/lists/below/images, etc.). The ''style''/''bodystyle'' parameter sets the style for the outer table, which the inner table inherits, but in advanced cases (meta-templates) it may be necessary to directly set the style for the inner table. This parameter provides access to that inner table so styles can be applied. Use at your own risk. ==== Microformats ==== :; ''bodyclass'' :: This parameter is inserted into the "class" attribute for the navbox as a whole. :; ''titleclass'' :: This parameter is inserted into the "class" attribute for the navbox's title caption. This template supports the addition of microformat information. This is done by adding "class" attributes to various data cells, indicating what kind of information is contained within. To flag a navbox as containing [[hCard]] information about a person, for example, add the following parameter: <pre> | bodyclass = vcard </pre> ''and'' <pre> | titleclass = fn </pre> ''or'' (for example): <pre><nowiki> | title = The books of <span class="fn">[[Iain Banks]]</span> </nowiki></pre> ...and so forth. See [[Wikipedia:WikiProject Microformats]] for more information on adding microformat information to Wikipedia, and [[microformat]] for more information on microformats in general. == Layout of table == ===Without image, above and below=== Table generated by {{tl|Navbox}} '''without''' ''image'', ''above'' and ''below'' parameters (gray list background color added for illustration only): {{{{PAGENAMETDOC}} | name = Navbox/doc | state = uncollapsed | liststyle = background: silver; | title = {{{title}}} | group1 = {{{group1}}} | list1 = {{{list1}}} | group2 = {{{group2}}} | list2 = {{{list2}}} | list3 = {{{list3}}} ''without {{{group3}}}'' | group4 = {{{group4}}} | list4 = {{{list4}}} }} ===With image, above and below=== Table generated by {{tl|Navbox}} '''with''' ''image'', ''above'' and ''below'' parameters (gray list background color added for illustration only): {{{{PAGENAMETDOC}} | name = Navbox/doc | state = uncollapsed | liststyle = background: silver; | image = {{{image}}} | title = {{{title}}} | above = {{{above}}} | group1 = {{{group1}}} | list1 = {{{list1}}} | group2 = {{{group2}}} | list2 = {{{list2}}} | list3 = {{{list3}}} ''without {{{group3}}}'' | group4 = {{{group4}}} | list4 = {{{list4}}} | below = {{{below}}} }} ===With image and without groups=== Table generated by {{tl|Navbox}} '''with''' ''image'', ''imageleft'', ''lists'', and '''without''' ''groups'', ''above'', ''below'' (gray list background color added for illustration only): {{{{PAGENAMETDOC}} | name = Navbox/doc | state = uncollapsed | liststyle = background: silver; | image = {{{image}}} | imageleft = {{{imageleft}}} | title = {{{title}}} | list1 = {{{list1}}} | list2 = {{{list2}}} | list3 = {{{list3}}} | list4 = {{{list4}}} }} == Examples == <!-- Please do not encourage folks to use <div> within Navboxes as (unless handled carefully) they can negate liststyles/groupstyles/etc. settings. --> === No image === <pre style="overflow: auto;"> {{Navbox | name = Navbox/doc | title = [[MSC Malaysia]] | listclass = hlist | group1 = Centre | list1 = * [[Cyberjaya]] | group2 = Area | list2 = * [[Klang Valley]] | group3 = Major landmarks | list3 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] * [[Technology Park Malaysia]] * [[Putrajaya]] * [[Cyberjaya]] * [[Kuala Lumpur International Airport]] | group4 = Infrastructure | list4 = * [[Express Rail Link]] * [[KL-KLIA Dedicated Expressway]] | group5 = Prime applications | list5 = * [[E-Government]] * [[MyKad]] }} </pre> {{{{PAGENAMETDOC}} | name = Navbox/doc | state = uncollapsed | title = [[MSC Malaysia]] | listclass = hlist | group1 = Centre | list1 = * [[Cyberjaya]] | group2 = Area | list2 = * [[Klang Valley]] | group3 = Major landmarks | list3 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] * [[Technology Park Malaysia]] * [[Putrajaya]] * [[Cyberjaya]] * [[Kuala Lumpur International Airport]] | group4 = Infrastructure | list4 = * [[Express Rail Link]] * [[KL-KLIA Dedicated Expressway]] | group5 = Prime applications | list5 = * [[E-Government]] * [[MyKad]] }} === With image, without groups === <pre style="overflow: auto;"> {{Navbox | name = Navbox/doc | title = [[MSC Malaysia]] | listclass = hlist | image = [[File:Flag of Malaysia.svg|80px|link=|alt=]] | list1 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] * [[Technology Park Malaysia]] * [[Putrajaya]] * [[Cyberjaya]] * [[Kuala Lumpur International Airport]] }} </pre> {{{{PAGENAMETDOC}} | name = Navbox/doc | title = [[MSC Malaysia]] | listclass = hlist | image = [[File:Flag of Malaysia.svg|80px|link=|alt=]] | list1 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] * [[Technology Park Malaysia]] * [[Putrajaya]] * [[Cyberjaya]] * [[Kuala Lumpur International Airport]] }} === With two images, without groups, multiple lists === <pre style="overflow: auto;"> {{Navbox | name = Navbox/doc | title = [[MSC Malaysia]] | listclass = hlist | image = [[File:Flag of Malaysia.svg|80px|link=|alt=]] | imageleft = [[File:Flag of Malaysia.svg|80px]] | list1 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] | list2 = * [[Express Rail Link]] * [[KL-KLIA Dedicated Expressway]] | list3 = * [[E-Government]] * [[MyKad]] | list4 = * [[Klang Valley]] }} </pre> {{{{PAGENAMETDOC}} | name = Navbox/doc | title = [[MSC Malaysia]] | listclass = hlist | image = [[File:Flag of Malaysia.svg|80px|link=|alt=]] | imageleft = [[File:Flag of Malaysia.svg|80px]] | list1 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] | list2 = * [[Express Rail Link]] * [[KL-KLIA Dedicated Expressway]] | list3 = * [[E-Government]] * [[MyKad]] | list4 = * [[Klang Valley]] }} === With image, groups, above, below === <pre style="overflow: auto;"> {{Navbox | name = Navbox/doc | title = [[MSC Malaysia]] | listclass = hlist | above = Above text goes here | image = [[File:Flag of Malaysia.svg|80px|link=|alt=]] | group1 = Centre | list1 = * [[Cyberjaya]] | group2 = Area | list2 = * [[Klang Valley]] | group3 = Major landmarks | list3 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] * [[Technology Park Malaysia]] * [[Putrajaya]] * [[Cyberjaya]] | group4 = Infrastructure | list4 = * [[Express Rail Link]] * [[KL-KLIA Dedicated Expressway]] | group5 = Prime applications | list5 = * [[E-Government]] * [[MyKad]] | below = Below text goes here }} </pre> {{{{PAGENAMETDOC}} | name = Navbox/doc | title = [[MSC Malaysia]] | listclass = hlist | above = Above text goes here | image = [[File:Flag of Malaysia.svg|80px|link=|alt=]] | group1 = Centre | list1 = * [[Cyberjaya]] | group2 = Area | list2 = * [[Klang Valley]] | group3 = Major landmarks | list3 = * [[Petronas Twin Towers]] * [[Kuala Lumpur Tower]] * [[Kuala Lumpur Sentral]] * [[Technology Park Malaysia]] * [[Putrajaya]] * [[Cyberjaya]] | group4 = Infrastructure | list4 = * [[Express Rail Link]] * [[KL-KLIA Dedicated Expressway]] | group5 = Prime applications | list5 = * [[E-Government]] * [[MyKad]] | below = Below text goes here }} == Child navboxes == {{Selfref|For additional examples, see the [[Template:Navbox/testcases|Navbox testcases page]].}} It is possible to place multiple navboxes within a single border with the use of the ''border'' parameter, or by specifying the first parameter to be "child". The basic code for doing this is as follows (which adds a subgroup for the first group/list area): <pre style="overflow: auto;"> {{Navbox | name = {{subst:PAGENAME}} | title = Title | group1 = [optional] | list1 = {{Navbox|child ...child navbox parameters... }} ... }} </pre> === Subgroups example === {{main|Template:Navbox subgroup}} This example shows how subgroups can be used. It is recommended that one use {{tl|Navbox subgroup}}, but the same result can be reached by using {{tl|Navbox}} with <code>border = child</code> or the first unnamed parameter set to <code>child</code>. The striping is alternated automatically. To remove the striping altogether, you can set <code>liststyle = background:transparent;</code> in each of the navboxes. {{{{PAGENAMETDOC}} | name = Navbox/doc | image = [[File:Flag of the United States.svg|100px|link=|alt=]] | state = uncollapsed | title = Multiple subgroup example | above = Above | below = Below | group1 = Group1 | list1 = List1 | group2 = Group2 | list2 = {{{{PAGENAMETDOC}}|child | evenodd = swap | group1 = Group2.1 | list1 = List1 | group2 = Group2.2 | list2 = List2 | group3 = Group2.3 | list3 = List3 }} | group3 = Group3 | list3 = List3 | group4 = Group4 | list4 = {{{{PAGENAMETDOC}}|child | evenodd = swap | group1 = Group4.1 | list1 = List1 | group2 = Group4.2 | list2 = List2 | group3 = Group4.3 | list3 = List3 }} }} === Multiple show/hides in a single container === {{main|Template:Navbox with collapsible groups}} The example below is generated using a regular navbox for the main container, then its list1, list2, and list3 parameters each contain another navbox, with <code>1 = child</code> set. The view (v), discuss (d), edit (e) navbar links are hidden using <code>navbar = plain</code> for each of them, or could be suppressed by just leaving out the ''name'' parameter (child navboxes do not require the name parameter to be set, unlike regular navboxes). {{{{PAGENAMETDOC}} | name = Navbox/doc | title = [[File:Blason France moderne.svg|x17px|link=|alt=]] [[File:Flag of France.svg|x17px|link=|alt=]] [[French colonial empire|Former French overseas empire]] | state = uncollapsed | list1 = {{{{PAGENAMETDOC}}|child | navbar = plain | title = [[French colonial empire|Former French colonies]] in [[Africa]] and the [[Indian Ocean]] | listclass = hlist | group1 = [[Mahgreb]] | list1 = * [[French rule in Algeria|Algeria]] * [[French Morocco|Morocco]] <small>([[Arguin|Arguin Island]])</small> * [[History of Tunisia|Tunisia]] | group2 = [[French West Africa]] | list2 = * [[History of Côte d'Ivoire#French Period|Côte d'Ivoire]] * [[French Dahomey|Dahomey]] * [[French Sudan]] * [[French Guinea|Guinea]] * [[History of Mauritania#French colonization and post-colonial history|Mauritania]] * [[History of Niger#Colonization|Niger]] * [[History of Senegal|Senegal]] * [[French Upper Volta|Upper Volta]] * [[French Togoland]] * [[James Island (The Gambia)|James Island]] | group3 = [[French Equatorial Africa]] | list3 = * [[Colonial Chad|Chad]] * [[History of Gabon|Gabon]] * [[History of the Republic of the Congo|Middle Congo]] * [[Oubangui-Chari]] | group4 = [[Comoros]] | list4 = * [[Anjouan]] * [[Grande Comore]] * [[Mohéli]] * [[History of Djibouti#French Interest|French Somaliland (Djibouti)]] * [[History of Madagascar#French control|Madagascar]] * [[Mauritius|Ile de France]] * [[Seychelles]] }} | list2 = {{{{PAGENAMETDOC}}|child | navbar = plain | title = [[French colonial empire|Former French colonies]] in the [[Americas]] | listclass = hlist | list1 = * [[New France]]{{spaces|2}}<small>([[Acadia]], [[Louisiana (New France)|Louisiana]], [[Canada, New France|Canada]], [[Newfoundland (island)|Terre Neuve]]) 1655–1763 </small> | list2 = * [[Inini]] * [[Berbice]] * [[Saint-Domingue]] * <small>[[Haiti]]</small> * [[Tobago]] * [[History of the British Virgin Islands|Virgin Islands]] * [[France Antarctique]] * [[France Équinoxiale]] | below = [[French West India Company]] }} | list3 = {{{{PAGENAMETDOC}}|child | navbar = plain | title = [[French colonial empire|Former French colonies]] in [[Asia]] and [[Oceania]] | listclass = hlist | group1 = [[French India]] | list1 = * [[Chandernagor]] * [[Coromandel Coast]] * [[History of Chennai|Madras]] * [[Mahé, India|Mahé]] * [[History of Pondicherry|Pondichéry]] * [[Karaikal]] * [[Yanam (India)|Yanaon]] | group2 = [[French Indochina]] | list2 = * [[Colonial Cambodia|Cambodia]] * [[History of Laos to 1945#French Laos|Laos]] * [[French Indochina|Vietnam]] <small>([[Annam (French colony)|Annam]], [[Cochinchina]], [[Tonkin]])</small> | group3 = Other Asian | list3 = * [[Alawite State|Alaouites]] * [[Republic of Hatay|Alexandretta-Hatay]] * [[Sri Lanka|Ceylon]] * [[Kwangchowan]] | group4 = [[Oceania]] | list4 = * [[New Hebrides]] ** [[History of Vanuatu|Vanuatu]] | below = [[French East India Company]] }} }} == Relationship with other Navbox templates == This navbox template is specifically designed to work in conjunction with two other sister templates: {{tl|Navbox with columns}} and {{tl|Navbox with collapsible groups}}. All three of these templates share common parameters for consistency and ease of use (such parameters are marked with an asterisk (*) in the [[#Parameter descriptions|parameter descriptions]] list hereinbefore). Most importantly, each template can be used as a child of one another (by using the {{para|border|child}} parameter, or by specifying the first unnamed parameter to be <code>child</code>. For example: <code><nowiki>{{Navbox|child ...}}</nowiki></code>, <code><nowiki>{{Navbox with columns|child ...}}</nowiki></code> or <code><nowiki>{{Navbox with collapsible groups|child ...}}</nowiki></code>.) == Technical details == * This template uses CSS classes for most of its looks, thus it is fully skinnable. * Internally this meta template uses HTML markup instead of wiki markup for the table code. That is the usual way we make meta templates since wiki markup has several drawbacks. For instance it makes it harder to use [[m:Help:ParserFunctions|parser functions]] and special characters in parameters. * For more technical details see the [[{{TALKPAGENAME}}|talk page]], the CSS classes in [[MediaWiki:Common.css]] and the collapsible table used to hide the box in [[MediaWiki:Common.js]]. === Intricacies === * The 2px wide border between groups and lists is drawn using the border-left property of the list cell. Thus, if you wish to change the background color of the template (for example <code>bodystyle = background:purple;</code>), then you'll need to make the border-left-color match the background color (i.e. <code>liststyle = border-left-color: purple;</code>). If you wish to have a border around each list cell, then the 2px border between the list cells and group cells will disappear; you'll have to come up with your own solution. * The list cell width is initially set to 100%. Thus, if you wish to manually set the width of group cells, you'll need to also specify the liststyle to have width: auto. If you wish to set the group width and use images, it's up to you to figure out the CSS in the groupstyle, liststyle, imagestyle, and imageleftstyle parameters to get everything to work correctly. Example of setting group width: :: <code>groupstyle = width: 10em;</code> :: <code>liststyle = width: auto;</code> * Adjacent navboxes have only a 1 pixel border between them (except in IE 6, which doesn't support the necessary CSS). If you set the top or bottom margin of <code>style/bodystyle</code>, then this will not work. * The default margin-left and margin-right of the outer navbox table are set to "auto;". If you wish to use navbox as a float, you need to manually set the margin-left and margin-right values, because the auto margins interfere with the float option. For example, add the following code to use the navbox as a float: ::<code>bodystyle = width: 22em; float: right; margin-left: 1em; margin-right: 0;</code> === Copying to other projects or wikis? === Using this template on other wikis requires [[HTML Tidy]] to be turned on. A version that does not require Tidy can be found at [[Wikipedia:WikiProject Transwiki/Template:Navbox]]. (That version generally shouldn't be used here on the English Wikipedia.) More detailed information on copying {{tlf|Navbox}} to other wikis can be found on the [[Template talk:Navbox|talk page]]. === Known issues === # If the heading of the navbox spans more than one line, the second line will be displayed to the right of center. This can be avoided by hard-coding linebreaks with {{tag|br|single|params=clear="all"}}. # In Internet Explorer 8 and 9, there is a bug when using <code>hlist</code>; navbox will fail to wrap the list to the next line if the list items start with an image, causing navbox to extend its width outside the screen. This can be fixed by adding <code>&amp;nbsp;</code> in front of the images. # Excessive use of the '''unsubstituted''' {{tlx|•}} template as a delimiter, can in extreme cases cause the wiki page rendering to fail&nbsp;— there is a limit to the number of templates that can be used on a page (example [[Ketamine]] where the inclusion of eleven Navboxes with hundreds of bullets caused the page load not to complete, only the substitution of the bullets in those navboxes cured the problem). Use of the <code>hlist</code> class avoids the delimiter transclusion issue altogether, as the delimiters are rendered via CSS. == See also == * {{tl|Otherarticles}} – a small navbox based on an existing category * {{tl|Navbar}} – Used for the navigation links in navbox. * {{tl|Nobold}} – To display text at normal font-weight within a context where the default font-weight is bold, e.g. header cells in tables. * {{tl|Sidebar}} – Vertically-aligned navigation templates. * [[Template:Navbox/testcases]] – For additional examples of template code. * [[Wikipedia:Line-break handling]] – The how-to guide about how to handle word wraps (line breaks) on Wikipedia, such as the wrapping of the link lists used in navboxes. * {{tl|Nowrap begin}}, {{tl|·}} and {{tl|•}} are '''deprecated''' in favor of the <code>hlist</code> class for formatting lists. See [[Template:Flatlist#Technical details|Flatlist]] for a technical explanation of how <code>hlist</code> works. {{Navigation templates}} <includeonly>{{#ifeq:{{SUBPAGENAME}}|sandbox|| <!-- Categories go below this line, please; interwikis go to Wikidata, thank you! --> [[Category:Navigational boxes| ]] [[Category:Templates generating microformats]] [[Category:Wikipedia metatemplates]] [[Category:Exclude in print]] }}</includeonly> 2445dfc383a8dec3f54eb1a579ed604ad24d0054 10 593 2471 2470 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <onlyinclude>{{#invoke:sidebar|sidebar | width = auto | bodystyle = border-spacing:0;background:#f7f7f7;padding:2px; | titleclass = navbox-title | title = Navbox suite | contentclass = plainlist | contentstyle = padding:0.25em;background:#fdfdfd; | content1 = *{{tl|Navbox}} *{{tl|Navbox subgroup}} *{{tl|Navbox with collapsible groups}} *{{tl|Navbox with columns}} *{{tl|Navboxes}} | navbarstyle = background:#fdfdfd;padding:0 5px }}</onlyinclude><!-- NOTE: A template MUST support all of the parameters marked with a cross in Template:Navbox/doc in order to be Navbox suite compliant. In particular, the name, state, border, and navbar parameters are especially important. --><noinclude> {{Documentation|content= [[Category:Navigational boxes| ]] [[Category:Documentation shared content templates]] [[Category:Wikipedia-internal navigational templates]] }}</noinclude> fd01b836fb9fc155d7963c59d432f242fa499552 10 594 2473 2472 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki Navboxes and other templates using the <code>navbox</code> or <code>vertical-navbox</code> attributes are <mark>not displayed on the [https://en.m.wikipedia.org/ Mobile Web site for Wikipedia]</mark>, which accounts for approximately 45% of readers.<noinclude> {{documentation}} [[Category:Notice and warning templates]] [[Category:Navigational meta-templates]] </noinclude> 7db55ab7c3ab670b306bcbaadb7cecf5f2ed7535 10 595 2475 2474 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {| class="wikitable hlist" style="margin-left: auto; margin-right: auto; width: auto; text-align: center; font-size: 90%;" |+ <span style="font-size: 130%;">Navigation templates comparison</span> |- style="line-height: 10pt;" ! style="text-align: left; padding-left: 4px; font-size: 111%;" | {{Navbar|Navigation templates|plain=1}} ! Collapsible !! Header color ! Image !! Groups !! Style (body) <br /> parameter/s !! Examples |- | style="text-align: left;" | {{tl|Navbox}} | collapsible || style="background: #ccf;" | navbox | Left/right of body || Yes || Yes || * {{tl|Solar System}} * {{tl|Governance of Greater London}} |- | style="text-align: left;" | {{tl|Navbox with collapsible groups}} | collapsible || style="background: #ccf;" | navbox | Left/right of body and/or in each list || Yes || Yes || * {{tl|Scouting}} * {{tl|University of Michigan}} |- | style="text-align: left;" | {{tl|Navbox with columns}} | collapsible || style="background: #ccf;" | navbox | Left/right of columns || No || Yes || * {{tl|Current U.S. Senators}} * {{tl|Historical regions of the Czech Republic}} |} {| class="wikitable" style="margin-left: auto; margin-right: auto; width: auto; text-align: center; font-size: 90%;" |+ <span style="font-size: 130%;">Collapsible attributes</span> |- style="line-height: 10pt;" ! Type !! CSS classes !! JavaScript !! Collapses when !! Custom <br /> initial&nbsp;state !! Nesting |- | style="text-align:left;" | [[Help:Collapsing|Collapsible tables]] | collapsible | Defined in [[MediaWiki:Common.js|Common.js]] | 2 or more autocollapse on page || Yes || Yes |}<noinclude> {{documentation}} [[Category:Navigational boxes| ]] [[Category:Documentation shared content templates]] </noinclude> <noinclude>{{convert to use Navbox}}</noinclude> 238343329afde083fd17089a3d8f5dbfda06e8b9 10 596 2477 2476 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{<includeonly>safesubst:</includeonly>#invoke:Ns has subpages|main}}<noinclude> {{documentation}} <!-- Categories go on the /doc subpage and interwikis go on Wikidata. --> </noinclude> 060d2d01af26cb67fd90a7c346a0d2d5e450a040 10 597 2479 2478 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <span class="plainlinks">[{{fullurl:{{{page|{{{1|Main Page}}}}}}|oldid={{{oldid|{{{2|}}}}}}}} {{{label|{{{title|{{{3|{{#if:{{{oldid|{{{2|}}}}}}|Old revision|Current version}} of''' {{{page|{{{1|'''a page'''}}}}}} '''}}}}}}}}}]</span><noinclude> {{documentation}} </noinclude> 5131b84bc0383b4e490d135545c19b235f16de56 10 598 2481 2480 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{#invoke:Message box|ombox}}<noinclude> {{documentation}} <!-- Categories go on the /doc subpage, and interwikis go on Wikidata. --> </noinclude> 0e54065432d540737b9e56c4e3a8e7f74d4534ea 10 599 2483 2482 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{#ifeq:{{#invoke:String|find|{{FULLPAGENAME}}|/sandbox%d*$|plain=false}}|0|{{{{#if:{{{1|}}}||FULL}}BASEPAGENAME}}|{{{{#if:{{{1|}}}||FULL}}PAGENAME}}}}<noinclude> {{Documentation|content= This template returns the current {{Tlx|FULLBASEPAGENAME}}, unless the title ends in <code>/sandbox</code> plus any number of digits, in which case it returns the {{tlx|FULLPAGENAME}}. It is primarily meant for demonstrating the sandbox version of templates in their documentation. This template takes one numbered parameter (<code>1</code>); if anything is in this parameter then it will return <code>&#123;&#123;BASEPAGENAME&#125;&#125;</code> and <code>&#123;&#123;PAGENAME&#125;&#125;</code>, which have no namespace prefix. }} [[Category:Wikipedia variable-like templates]] </noinclude> 60d0ba16d0cb174077780998dd2d8ce252515d99 10 600 2485 2484 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <code class="nowrap" {{#if:{{{plain|}}}|style="border:none;background-color:inherit;color:inherit;"}}>&#124;{{#if:{{{1|}}}|{{{1}}}&#61;}}{{{2|}}}</code><noinclude> {{Documentation}} <!--Categories and interwikis go near the bottom of the /doc subpage.--> </noinclude> 66770157bb51b0aabb5b874e4f1bb8f04c80915c 10 601 2487 2486 2017-09-15T13:04:11Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{#switch:{{{2|NONE}}} |NONE|hatnote|hat={{Hatnote|1=<span class="plainlinks selfreference noprint">{{{1}}}</span>}} |inline=<span class="plainlinks selfreference" style="font-style: italic;"><!--Same style as class hatnote.-->{{{1}}}</span> |<!--Matching the empty string here for unprintworthy content is for backwards compatibility with the 2006-2008 version. Do not depend on it!-->=<span class="plainlinks selfreference noprint">{{{1}}}</span> |#default={{error|Second parameter must be <code>hatnote</code>, <code>hat</code>, or <code>inline</code>}} }}<noinclude> {{Documentation}} <!-- PLEASE ADD THIS TEMPLATE'S CATEGORIES THE /doc SUBPAGE, AND INTERWIKIS TO WIKIDATA, THANKS --> </noinclude> a1de324335111c757641de6fd35b8d280363a6dd 10 602 2489 2488 2017-09-15T13:04:12Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <span class="nowrap">{{#iferror:{{#expr:{{{1|1}}}}} |{{#switch:{{{1}}} |fig=&#8199; |en=&ensp; |em=&emsp; |thin=&thinsp; |hair=&#8202; |&nbsp; }} |{{#invoke:String|rep|{{#switch:{{{2}}} |fig=&#8199; |en=&ensp; |em=&emsp; |thin=&thinsp; |hair=&#8202; |&nbsp; }}|{{{1|1}}}}} }}</span><noinclude> {{documentation}} </noinclude> a9ed762825e7579f15dcb9b171b0c1c3bf524b3f 10 603 2491 2490 2017-09-15T13:04:12Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <code class="{{#ifeq:{{{wrap|}}}|yes|wrap|nowrap}}" style="{{#ifeq:{{{style|}}}|plain|border:none;background:transparent;|{{{style|}}}}}"><!-- Opening tag -->{{#switch:{{{2|pair}}} |c|close = |e|empty|s|single|v|void |o|open |p|pair = &lt;{{{1|tag}}}{{#if:{{{params|}}}|&#32;{{{params}}}}} }}<!-- Content between tags -->{{#switch:{{{2|pair}}} |c|close = {{{content|}}} |e|empty|s|single|v|void = &#32;&#47;&gt; |o|open = &gt;{{{content|}}} |p|pair = {{#ifeq:{{{1|tag}}}|!--||&gt;}}{{{content|...}}} }}<!-- Closing tag -->{{#switch:{{{2|pair}}} |e|empty|s|single|v|void |o|open = |c|close |p|pair = {{#ifeq:{{{1|tag}}}|!--|--&gt;|&lt;&#47;{{{1|tag}}}&gt;}} }}<!-- --></code><noinclude> {{Documentation}} </noinclude> 9a9d57bd22b1e66278e044e69acf71bb7e266d37 10 604 2493 2492 2017-09-15T13:04:12Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki {{#ifeq: {{{1}}}| adaptive |<table class="plainlinks advert" role="presentation" style="margin: 0 10%; border: 1px solid #aaa; border-left: 10px solid #1e90ff; background: #fbfbfb;"><tr><td class="mbox-image" style="width:71px;padding:3px;">[[File:Different devices simple.svg|65x65px|link=|alt=]]</td><td class="mbox-text"><span class="mbox-text-span">This template is [[Adaptive web design|adaptive]] and <strong>displays differently in mobile and desktop view</strong>. Read the documentation for an explanation of the differences and why they exist.</span></td></tr></table> | {{#ifeq: {{{1}}} | nomobile|<table class="plainlinks advert" role="presentation" style="margin: 0 10%; border: 1px solid #aaa; border-left: 10px solid #1e90ff; background: #fbfbfb;"><tr><td class="mbox-image" style="width:55px">[[File:Handheld devices no.svg|55px|link=|alt=]]</td><td class="mbox-text"><span class="mbox-text-span">This template does not display in the mobile view of Wikipedia; it is <strong>desktop only</strong>. Read the documentation for an explanation.</span></td></tr></table>|{{#ifeq: {{{1}}} | nodesktop |<table class="plainlinks advert" role="presentation" style="margin: 0 10%; border: 1px solid #aaa; border-left: 10px solid #1e90ff; background: #fbfbfb;"><tr><td class="mbox-image" style="width:55px">[[File:Desktop devices no.svg|55px|link=|alt=]]</td><td class="mbox-text"><span class="mbox-text-span">This template does not display in the desktop view of Wikipedia; it is <strong>mobile only</strong>. Read the documentation for an explanation.</span></td></tr></table>| }}| }}| }}<noinclude>{{Documentation}}</noinclude> 97a1cb4724de8d1e5c42332f8b9fbcfaa43093eb 10 605 2495 2494 2017-09-15T13:04:12Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki &#123;&#123;[[Template:{{{1}}}|{{{1}}}]]&#125;&#125;<noinclude> {{documentation}} <!-- Categories go on the /doc subpage and interwikis go on Wikidata. --> </noinclude> 91be693cd63410db06fc933eddb412ba433564dc 10 606 2497 2496 2017-09-15T13:04:12Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <span class="nowrap">&#123;&#123;{{#if:{{{1|}}}|{{{1}}}| tlf&#124;...}}<!-- -->{{#ifeq:{{{2|x}}}|{{{2|}}}| &#124;{{{2}}} | }}<!-- -->{{#ifeq:{{{3|x}}}|{{{3|}}}| &#124;{{{3}}} | }}<!-- -->{{#ifeq:{{{4|x}}}|{{{4|}}}| &#124;{{{4}}} | }}<!-- -->{{#ifeq:{{{5|x}}}|{{{5|}}}| &#124;{{{5}}} | }}<!-- -->{{#ifeq:{{{6|x}}}|{{{6|}}}| &#124;{{{6}}} | }}<!-- -->{{#ifeq:{{{7|x}}}|{{{7|}}}| &#124;{{{7}}} | }}<!-- -->{{#ifeq:{{{8|x}}}|{{{8|}}}| &#124;{{{8}}} | }}<!-- -->{{#ifeq:{{{9|x}}}|{{{9|}}}| &#124;{{{9}}} | }}<!-- -->&#125;&#125;</span><noinclude> {{documentation}} <!-- Add categories and interwikis to the /doc sub-page, not here! --> </noinclude> c4b4c9f5569053b1a7176f4ef16ee85e80f1350f 10 607 2499 2498 2017-09-15T13:04:12Z Fli091 93 1 revision imported: Import https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Transwiki/Template:Navbox wikitext text/x-wiki <includeonly><!-- --><code><!-- --><nowiki>{{</nowiki>{{#if:{{{subst|}}} |[[Help:Substitution|subst]]:}}<!-- -->[[{{{LANG|}}}{{{SISTER|}}}{{ns:Template}}:{{{1|}}}|{{{1|}}}]]<!-- -->{{#if:{{{2|}}} |&#124;{{{2}}}}}<!-- -->{{#if:{{{3|}}} |&#124;{{{3}}}}}<!-- -->{{#if:{{{4|}}} |&#124;{{{4}}}}}<!-- -->{{#if:{{{5|}}} |&#124;{{{5}}}}}<!-- -->{{#if:{{{6|}}} |&#124;{{{6}}}}}<!-- -->{{#if:{{{7|}}} |&#124;{{{7}}}}}<!-- -->{{#if:{{{8|}}} |&#124;{{{8}}}}}<!-- -->{{#if:{{{9|}}} |&#124;{{{9}}}}}<!-- -->{{#if:{{{10|}}} |&#124;{{{10}}}}}<!-- -->{{#if:{{{11|}}} |&#124;{{{11}}}}}<!-- -->{{#if:{{{12|}}} |&#124;''…''}}<!-- --><nowiki>}}</nowiki><!-- --></code><!-- --></includeonly><noinclude> {{Documentation}}</noinclude> 5633c008ca0a8c29aa9cea811c02e4cd5c61337b 0 546 2501 2302 2017-09-15T13:14:29Z Fli091 93 Added [[Category:Mikroelektronikk]] wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = Run LVS by pressing Assura -> Run LVS. [[Category:Mikroelektronikk]] f154b64e56d03b0c92ffab9bb005c4b7f2123eeb 0 469 2502 2060 2017-09-15T13:14:48Z Fli091 93 Added [[Category:Mikroelektronikk]] wikitext text/x-wiki = SAMPA DAQ Registers = == Command and Control module registers == The registers for the command and control module, located at address 0x0000 from the UART or 0xFF200000 from the HPS, is listed in table 4.1 {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | SC_ADD | [15:0] | 0x00 | RW | 0x00 | [4:0] | Slow control: Register address |- | | | | RW | 0x00 | [9:5] | Slow control: Channel address |- | | | | RW | 0x00 | [13:10] | Slow control: Chip address |- | | | | RW | 0x00 | [14] | Slow control: Broadcast |- | | | | RW | 0x00 | [15] | Slow control: Write/ not read |- | SC_DAT | [19:0] | 0x01 | RW | 0x00 | [19:0] | Slow control: Data to write |- | SC_MASK | [19:0] | 0x02 | RW | 0x00 | [19:0] | Slow control: Mask for writing * |- | CMD | [31:0] | 0x03 | RW | 0x00 | [15:0] | Commands, see table 4.2 |- | | | | RW | 0x00 | [31:15] | Loop count for commands |- | SC_RLT | [19:0] | 0x04 | R | 0x00 | [12:0] | Slow control: Response from SAMPA |- | SC_ERR | [1:0] | 0x05 | R | 0x00 | [0] | Error: Timeout waiting for response from slow control |- | | | | R | 0x00 | [1] | Error: Response from SAMPA not as expected |- | LNK_STS | [31:0] | 0x06 | R | 0x00 | [31:0] | Ethernet link status * |- | EVT_CFG | [31:0] | 0x07 | RW | 0x01 | [1:0] | Test signal output, see table 4.3 |- | | | | RW | 0x00 | [2] | Enable SLVS testing |- | | | | RW | 0x00 | [3] | Enable continuous readout of shiftregister |- | | | | RW | 0x00 | [31:3] | Reserved * |- | EVT_CNT | [31:0] | 0x08 | R | 0x00 | [31:0] | Reserved * |- | EV_BL | [31:0] | 0x09 | R | 0x00 | [31:0] | Reserved * |- | SMP_STS1 | [30:0] | 0x0A | R | | | Status of signals to and from SAMPA (updated every clock cycle) |- | | | | R | | [12:0] | Test data output from SAMPA |- | | | | R | | [16:13] | Serial out [3:0] |- | | | | R | | [18:17] | Number of serial out |- | | | | R | | [19] | Enable ZSU |- | | | | R | | [20] | Enable BC2 |- | | | | R | | [21] | Enable TCFU |- | | | | R | | [22] | Enable BC1 |- | | | | R | | [25:23] | Select test output |- | | | | R | | [26] | Select ADC0 or test input |- | | | | R | | [30:27] | Chip address |- | SMP_STS2 | [5:0] | 0x0B | R | | | Status of signals to and from SAMPA cont. |- | | | | R | | [0] | Slow control to SAMPA |- | | | | R | | [1] | Slow control from SAMPA |- | | | | R | | [2] | Reset_n |- | | | | R | | [3] | Event trigger |- | | | | R | | [4] | Heartbeat trigger |- | | | | R | | [5] | Sync signal |- | SMP_CFG | [13:0] | 0x0C | RW | | | SAMPA static signals, see SAMPA spec document for further details |- | | | | RW | 0x02 | [1:0] | Number of serial out |- | | | | RW | 0x00 | [2] | Enable ZSU |- | | | | RW | 0x00 | [3] | Enable BC2 |- | | | | RW | 0x01 | [4] | Enable TCFU |- | | | | RW | 0x01 | [5] | Enable BC1 |- | | | | RW | 0x03 | [8:6] | Select test output |- | | | | RW | 0x01 | [9] | Select ADC0 or test input |- | | | | RW | 0x01 | [13:10] | Chip address |- | SLVS_ERR | [15:0] | 0x0D | R | 0x00 | | SLVS errors detected |- | RAD_ERR | [31:0] | 0x0E | R | | | Errors detected in shiftregister test |- | | | | R | 0x00 | [15:0] | Bit 0 errors |- | | | | R | 0x00 | [31:16] | Bit 1 errors |- | VER | [31:0] | 0x0F | R | | | SVN version build was based on in dec |} Commands for command and control unit. {| class="wikitable" ! Value ! Description |- | 0x1 | Reset FPGA and SAMPA |- | 0x2 | Reset SAMPA |- | 0x3 | Send event trigger |- | 0x4 | Send heartbeat trigger |- | 0x5 | Send sync signal |- | 0x6 | Run readout of shiftregister once (RAD) |- | 0x7 | Reset errors in shiftregister count (RAD_ERR) |- | 0x8 | Execute slow control command |- | 0x9 | Reset HPS |} Test signals available for generation. {| class="wikitable" ! Value ! Description |- | 0x0 | Constant zeros |- | 0x1 | Sine wave, full wave, 512 samples pulse width |- | 0x2 | Saw wave, full wave, 512 samples pulse width |- | 0x3 | Triangle wave, full wave, 1024 samples pulse width |} == Data manager registers == The registers for the data manager module, located at address 0x0040 from the UART or 0xFF201000 from the HPS, is listed in table 4.4. {| class="wikitable" ! Register name ! ! Address ! Type ! Default ! ! Description |- | CNTRL | [7:0] | 0x00 | RW | 0x00 | | Control register |- | | | | RW | 0x00 | [0] | Enable acquisition |- | | | | RW | 0x00 | [7:1] | Reserved |- | PKT0 | [31:0] | 0x01 | R | 0x00 | [31:0] | Packets written to memory from channel 0 |- | PKT1 | [31:0] | 0x02 | R | 0x00 | [31:0] | Packets written to memory from channel 1 |- | PKT2 | [31:0] | 0x03 | R | 0x00 | [31:0] | Packets written to memory from channel 2 |- | PKT3 | [31:0] | 0x04 | R | 0x00 | [31:0] | Packets written to memory from test-input/ADC |- | FIFO0 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 0 |- | FIFO1 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 1 |- | FIFO2 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 2 |- | FIFO3 | [8:0] | 0x05 | R | 0x00 | [8:0] | Number of 64 bit words in FIFO 3 |} [[Category:Mikroelektronikk]] 4dcf6de4a617c1549ae556a2f850434957985010 0 468 2503 2055 2017-09-15T13:15:01Z Fli091 93 Added [[Category:Mikroelektronikk]] wikitext text/x-wiki = SAMPA MPW1 Registers = == Channel specific registers == These are registers specific to each channel. By using a broadcast command, all channels can be written at the same time.<br /> {| class="wikitable" ! Register name ! ! Address ! Type ! Default value ! ! Description |- | K1 | [12:0] | 0x00 | RW | 0x00 | [12:0] | First pole of the TCFU |- | K2 | [12:0] | 0x01 | RW | 0x00 | [12:0] | Second pole of the TCFU |- | K3 | [12:0] | 0x02 | RW | 0x00 | [12:0] | Third pole of the TCFU |- | K4 | [12:0] | 0x03 | RW | 0x00 | [12:0] | Fourth pole of the TCFU |- | L1 | [12:0] | 0x04 | RW | 0x00 | [12:0] | First zero of the TCFU |- | L2 | [12:0] | 0x05 | RW | 0x00 | [12:0] | Second zero of the TCFU |- | L3 | [12:0] | 0x06 | RW | 0x00 | [12:0] | Third zero of the TCFU |- | L4 | [12:0] | 0x07 | RW | 0x00 | [12:0] | Fourth zero of the TCFU |- | ZSTHR | [19:0] | 0x08 | RW | 0x0A | [9:0] | Zero suppression threshold |- | | | | RW | 0x00 | [19:10] | Zero suppression offset |- | ZSCFG | [6:0] | 0x09 | RW | 0x02 | [1:0] | Glitch filter, minimum accepted pulse |- | | | | RW | 0x07 | [4:2] | Post-samples |- | | | | RW | 0x03 | [6:5] | Pre-samples |- | VFPED | [19:0] | 0x0A | RW | 0x00 | [9:0] | BC1 Fixed pedestal |- | | | | R | 0x00 | [19:10] | BC1 variable pedestal |- | CTE | [9:0] | 0x0B | RW | 0x00 | [9:0] | Channel specific noise |- | PMDTA | [9:0] | 0x0C | RW | 0x00 | [9:0] | Data to be stored in the pedestal memory |} == Global registers == These are global registers and does not accept broadcast commands.<br /> {| class="wikitable" ! Register name ! ! Address ! Type ! Default value ! ! Description |- | PMADD | [9:0] | 0x0D | RW | 0x00 | [9:0] | Pedestal memory address |- | BC2THR | [19:0] | 0x0E | RW | 0x03 | [8:0] | Lower threshold of moving average filter |- | | | | RW | 0x03 | [17:9] | Higher threshold of moving average filter |- | | | | RW | 0x01 | [19:18] | Number of taps in moving average filter |- | TRCFG | [19:0] | 0x0F | RW | 0x00 | [7:0] | Number of pre-samples (Pretrigger delay), max 191 |- | | | | RW | 0x3FD | [17:8] | Number of samples per event, max 1021 |- | DPCFG | [11:0] | 0x10 | RW | 0x00 | [3:0] | BC1 mode, see ALTRO manual |- | | | | RW | 0x00 | [4] | BC1 polarity |- | | | | RW | 0x07 | [6:5] | BC2 pre-samples |- | | | | RW | 0x07 | [10:7] | BC2 post-samples |- | | | | RW | 0x01 | [1] | BC2 moving average filter enable |- | VACFG | [7:0] | 0x11 | RW | 0x00 | [1:0] | Number of neighbors, not in use |- | | | | RW | 0x01 | [3:2] | Number of serial out, see table 1.5 |- | | | | RW | 0x00 | [4] | Pedestal mode enabled (zero suppression threshold 0) |- | | | | RW | 0x01 | [5] | Power save mode enabled |- | | | | RW | 0x00 | [6] | TCFU enabled |- | | | | RW | 0x01 | [7] | Continuous mode enabled |- | BC1THR | [13:0] | 0x12 | RW | 0x03 | [4:0] | Lower threshold of variable pedestal filter |- | | | | RW | 0x03 | [9:5] | Higher threshold of variable pedestal filter |- | | | | RW | 0x01 | [13:10] | Number of taps in variable pedestal filter |- | TRCNT | [15:0] | 0x13 | R | 0x00 | [15:0] | Trigger count |- | HWADD | [4:0] | 0x14 | R | 0x00 | [4:0] | Chip address (hardware address) |- | ERRORS | [5:0] | 0x15 | R | 0x00 | [0] | Parity error in received instruction |- | | | | R | 0x00 | [1] | Instruction error |- | | | | R | 0x00 | [2] | Trigger overlap |- | | | | R | 0x00 | [3] | SEU in MMU SM (not implemented) |- | | | | R | 0x00 | [4] | SEU in interface SM (not implemented) |- | BXCNT | [19:0] | 0x16 | R | 0x00 | [19:0] | Bunch crossing counter |} == Command registers == These are command registers and can only be written to. The value doesn’t matter as only the access is detected.<br /> {| class="wikitable" ! Register name ! Address ! Type ! Description |- | SWTRG | 0x1B | W | Software trigger (not implemented) |- | TRCLR | 0x1C | W | Clear trigger counter |- | ERCLR | 0x1D | W | Clear errors |- | BXCLR | 0x1E | W | Clear bunch crossing counter |- | SRST | 0x1F | W | Software reset |} [[Category:Mikroelektronikk]] fdcff9f54eefccf0a0f158aa3b6293c2202b4177 0 467 2504 2421 2017-09-15T13:15:12Z Fli091 93 Added [[Category:Mikroelektronikk]] wikitext text/x-wiki == SAMPA MPW1 documentation == <center>[[Image:sampa.png]]</center> <pre style="color: red"> This page has moved to https://twiki.cern.ch/twiki/bin/view/ALICE/SAMPA</pre> [[Category:Mikroelektronikk]] 6d5ca13c9de9abd7df09044383661f5fe5235755 0 539 2505 2280 2017-09-15T13:15:38Z Fli091 93 Added [[Category:Mikroelektronikk]] [[Category:VHDL]] wikitext text/x-wiki Obs! Fra Quartus Prime Handbook: Gate-level timing simulation of an entire design can be slow and should be avoided. Gate-level timing simulation is supported only for the Stratix IV and Cyclone IV device families. Use TimeQuest static timing analysis rather than gate-level timing simulation. ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneIV-chip. Vi valgte EP4CE115F29. Det er chipen på Terasic DE2-115. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. I simulation/modelsim/ finner vi nå add_sub_alu.vho og add_sub_alu_vhd.sdo. Vho-filen(VHDL Output File) er filen som inneholder nå det opprinnelige designet, men også mange nye moduler med cycloneive-prefix. Disse entitetene beskriver ressurser på den fysiske FPGA-chipen. Sdo-filen(Standard Delay Format Output File) inneholder detaljer om delay fra hver modul på chippen. ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila for designet add_sub_alu.vhd og testbenken alu_tb.vhd. Så legg vi til fila som Quartus generte i prosjektdir til simulation/modelsim/add_sub_alu.vho. Den Quartus-genererte filen vil ha samme entitetsnavn som den opprinnelige, og vil derfor ikke kunne simuleres samtid. Vi endrer derfor den genererte filen til å ha entiteten 'add_sub_alu_synth' og architecturen 'structure' (i vårt tilfelle endret den seg til structure automatisk). Vi kan nå kompilere filene våre og deretter simulere testbenken. I testbenken vår ser vi at vi har kalt den syntiserte entiteten alu_synt. Dette skal vi bruke nå. ==Simulering med timing== Velg Start Simulation - deretter work og alu_tb. Se så på SDF-fanen. Legg til add_sub_alu_vhd.sdo generert av Quartus tidligere. Under apply to region må du skrive: /alu_tb/alu_synt Dette er altså området vi ønsker at sdo-filen skal gi informasjon om. Trykk så OK. add wave * run -all Vi kan nå sammenligne utsignalene for den usyntiserte og den syntiserte ALU-komponenten. ==Konklusjon== Vi ser at vi får masse feil før 50 ns. Dette skyldes at den opprinnelige komponenten ikke har definerte signaler før de første klokkeflankene, mens den syntiserte komponenten ikke kan ha udefinerte signaler. Senere får vi feil når signalene skifter. Dette skyldes at den syntiserte komponenten bruker lengre tid på å sende ut riktig signal, og vil også glitche mellom verdier før den stabiliserer seg på riktig verdi. ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] [[Category:VHDL]] ff53e12770109ac10af013580262902acec300e8 0 315 2506 1365 2017-09-15T13:16:51Z Fli091 93 Added [[Category:Mikroelektronikk]] [[Category:VHDL]] wikitext text/x-wiki ==Modeling concept== there are 3 domains of modeling: * function * structure * geometry each provides a basic modeling concept. a module e.g. a register is an '''entity''', it's inputs ans outputs are called '''ports'''. an '''architecture''' is the internal implementation of an entity. it describes the behavior of an entity. architectures includes only '''processes''', collection of actions which are executed in sequences. types of action that can be performed: * evaluating expressions * assigning variables and values * conditional and repeated execution * subprogram calls '''''behavioral architecture''''': function of an entity is described in an abstract way. e.g. <pre> entity srlatch is port ( s,r : in std_logic; q,qb : out std_logic); end srlatch; architecture behave of calc is begin foo: process begin Q <= S nand QB; QB <= R nand Q; end process foo; end architecture behave; </pre> '''''structural architecture''''': only interconnecting subsystems <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; entity nand2 is port( a,b : in std_logic; q : out std_logic); end nand2; architecture basic of nand2 is begin q <= a nand b after 2 ns; end basic; </pre> <pre> entity srlatch is port( s,r: in std logic; q,qb: out std_logic); end srlatch; architecture struct of srlatch is begin sq: entity work.nand2(basic) port map ( a => s, b => qb, q => q ); rq: entity work.nand2(basic) port map ( a => r, b => q, q => qb ); end architecture struct; </pre> ===subprograms=== subprograms are '''procedures''', a collection of statements executed for their effect, and '''functions''', a collection of statements to compute a result. ====procedures==== variables etc. defined in the header are local variables. <pre> procedure proc_name is variable total : real :=0.0; --this is a local variable! begin for index in samples loop total = total +sample(index); end loop; answer:=total; end procedure proc_name; </pre> procedures without parameters is called by it's name from any place in architecture. other procedures can also call procedures in their body. <pre> proc_name; </pre> it is possible to use procedures with parameters. ====functions==== generalization of expressions, combined values with operators and produce new values. the type of result is specified. <pre> function limit (val, min, max: integer) return integer is begin if val > max then return max; elseif val < min then return min; else return val; end if; end function; </pre> a function is called in the architecture like this: <pre> newval := limit(current_val, 10, 100); newval2 := 2 + limit(current_val, 10, 100); </pre> ===Packages=== grouping a collection of related declarations to serve common purpose. seperat design units that can be worked on independently, reused in different parts of design. the can be written along with entities and architecture and are analyzed separately. it is also possible to place a package in an other library, in that case the lib "work" has to be replaced by the lib including the package. the external view is specified in the '''package declaration''', the implementation is defind in the '''package body'''. ====package declaration==== the package declaration hosts type, constand, subprogram, signal ... declarations which are shared within the model. it defines the interface to a package. in the model then you just need to refer to the package: <pre> package yourpackagename is --declaration constant foo: std_logic_vector(7 downto 0) := X"01"; type foobar is array (foobar2) of somethingelse; end package yourpackagename; </pre> <pre> use yourpackagename.all; entity yourentityname is port ( fooport : in work.yourpackagename.foo; foobarport : in work.yourpackagename.foobar; ); end entity yourentityname; </pre> ====package body==== no package body is needed if pkg declaration contains other kinds of declarations like types, signals or fully specified constants. in case of subprograms body needed to fill in missing informations. items declared in body must include full declaration of subprograms as they are in the pkg declaration. that means that types, modes, default constants... must bee repeated exactly. ===components=== to build hierarchical designs, used to describe interconnections in subsystems in a design. component declarations are written in the declarative part of the architecture (before the ''begin''). it is an alternative to use entity declarations (see structural design). an entity declaration defines a real module, it's a separate design. a component declaration defines a virtual module in the architecture body. "for this architecture we assume there is a module specified by this component". ===configurations=== in a configuration file the declaration can be made in which case which entity is using which architecture. the architectures may vary e.g. in case of simulation or synthesis. A '''configuration declaration''' is a design unit which can be compiled separately. In a configuration declaration the binding of all components which are part of a certain entity can be specified. also generic maps can be set. <pre> configuration config_identifier of entity_name is for architecture_name for all : component_identifier use entity lib_name.entity_name2(architecture_name2); --binding_indication end for; for bgo_channel_1 : bgo_channel use entity mxgs_bgo_lib.bgo_channel(struct) generic map( g_bgo_channel => "01" ); end for; end for; end config_identifier; </pre> [[Category:Mikroelektronikk]] [[Category:VHDL]] c74f5081678ee47106e21746e18c989bacced132 0 35 2507 2093 2017-09-15T13:20:17Z Fli091 93 Added [[Category:Mikroelektronikk]] [[Category:VHDL]] wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> ssh -X mikroserver3 mentor vsim & </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim -voptargs=+acc SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscillasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen. ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. [[Category:VHDL]] [[Category:Mikroelektronikk]] cf59e45f5a8770be50efa955834620265089918c 2 608 2508 2017-09-15T13:25:12Z Fli091 93 created userpage with email wikitext text/x-wiki [mailto:fli091@uib.no mailto:fli091@uib.no] 831e4d30b6cf682d0e16c2e9d561650da0edc914 0 509 2509 2242 2017-09-15T13:26:08Z Fli091 93 Added [[Category:Mikroelektronikk]] [[Category:VHDL]] wikitext text/x-wiki To download Vivado for free you must first create an account. By following this link [http://www.xilinx.com/support/download.html/ Xilinx web page] you will enter Xilinx download page. For this tutorial we will be using the 2015.4 version. To download for Windows Vivado HLx 2015.4 Web Install for Windows with SDK (EXE - 49.32 MB) For linux Vivado HLx 2015.4 Web Install for Linux with SDK (BIN - 76.98 MB) Run the installer and this will show, press next [[File:1.png]] Type your user name and password and press next [[File:2.png]] Agree to everything!!! Or else?!?! [[File:3.png]] Choose Vivado HL WebPACK [[File:4.png]] Make sure the Software Development Kit, Artix-7, Install Cable Drivers, and Acquire or Manage a License Key are all checked and click next. The DocNav file is not necessary but it allows you to * Find answers to your questions quickly through the integrated search * Manage documents on your desktop through the Download Manager * Always ensures you are reading the latest version of documentation Detailed information about using the tool and its features can be found in the Online Help Menu which you can access after installation. [[File:5.png]] Choose a directory to Install you Vivado product, make sure you have adequate free space on your hard drive. [[File:6.png]] The final screen summarizes your selections. Click install, and the installer will begin downloading the files it needs to install Vivado. When it is done this screen will pop up. [[File:7.png]] Click ok and the license manager should open up. If not open Vivado press Help=>obtain a license key and this window will open. Choose “Get Free SDK, Vivado WebPACK” and then press Connect Now. [[File:8.png]] You will be redirected to Xilinx home page were you will need to sign in with user name and password. After clicking “sign in”, press “next” and this site will pop up [[File:9.png]] Choose “Vivado Design Suite: HL WebPACK, Node-Locked License……..” and press Generate Node-Locked License. Next this window will pop up. [[File:10.png]] Click next and a new window will pop up, click next again and this will show [[File:11.png]] Open your E-mail and download the attached Xilinx.lic file. When you go back to the license manager this will show, press cancel. [[File:12.png]] Go to Load License in the left menu. You should see this [[File:13.png]] Click Copy License and upload the Xilinx.lic file and you will get this message [[File:14.png]] If you now press the view license status in the left menu, you should see this [[File:15.png]] You can now close the license manager and Vivado is good to go. [[Category:Mikroelektronikk]] [[Category:VHDL]] 26850cca63cb93b9fa6f5b737800573acc455853 0 538 2510 2273 2017-09-15T13:26:36Z Fli091 93 Added [[Category:Mikroelektronikk]] [[Category:VHDL]] wikitext text/x-wiki If you want to use the vga controller remember to * copy-paste the vga.txt file and save it as vga.vhd * copy-paste the Nexys4_Master.txt file and save it as Nexys4_Master.xdc The vga controller is using a BRAM block to store pixel values. Each pixel has 12-bits and number of pixels projected to the screen is 480x640=307200 * sw_i(15) -- active high, write enable * sw_i(11 downto 0) -- 12-bits for colour changing the screen CREATING NEW PROJECT Press create new project [[File:16.png|400px]] Press next on the first window that pops up, then you can choose were you want to store your project, click next. [[File:17.png|400px]] Choose RTL project and click next [[File:18.png|400px]] Add your VHDL file if you have one, if you don’t you can add the VGA-controller file just to make sure that everything works properly. Click next [[File:19.png|400px]] Click next [[File:20.png|400px]] Add the Nexys4_Master.xdc , this will connect all your I/O, LED, SW etc. [[File:21.png|400px]] Choose the xca100tcsg324-1 and click next and then finish. [[File:22.png|400px]] Vivado will open, now you can make your own VHDL code or you can follow instruction further if you want to use the VGA controller. If you want to make your own code you can skip the IP part and go to generate bitstream to see how you should implement your code on the FPGA. [[File:23.png|400px]] Adding IP’s, clk generator 25.2MHz and BRAM. Click IP Catalog and then [[File:24.png|400px]] Search for Clocking Wizard and enter and this will pop up, clocking option should look like this, remember to change the Component name! [[File:25.png|400px]] Change the output clock to 25.2MHz [[File:26.png|400px]] Port renaming: use names that explains your component, and click OK [[File:27.png|400px]] This should pop up, click generate [[File:28.png|400px]] Adding BRAM, search for bram and enter the Block Memory Generator and this should pop up. Remember component name [[File:29.png|400px]] Port A Options, write width = 12bits, write depth = 307200=(480*640 pixels projected on screen), then click OK and then generate as before and wait until the synthesis is done. [[File:30.png|400px]] GENERATE BITSTREAM: click generate bitstream [[File:31.png|400px]] If this pops up click yes [[File:32.png|400px]] If this message shows, just click ok, it only means that you have pins activated in your Nexys4_Master.xdc that are not in use. [[File:33.png|400px]] If later on want to change witch pins are active on your board you can configure this by entering the Nexys4_Master.xdc [[File:34.png|400px]] When completed, choose “Open Hardware Manager” and click ok [[File:35.png|400px]] At this point connect your NEXY4 board . In the left menu under “program and debug”, click open target => open new target [[File:36.png|400px]] Open new Hardware target will pop up, click next two times and this will show. Choose JTAG clock freq. 30 000 000, click next and then finish [[File:37.png|400px]] Now you can program your device, click program device and choose your FPGA [[File:38.png|400px]] Click program and your device is ready to go. [[File:39.png|400px]] [[Category:Mikroelektronikk]] [[Category:VHDL]] d521b94e988572c76a527825a8ea022d6911d5a4 14 609 2511 2017-09-15T13:27:58Z Fli091 93 First try to create a VHDL subcategory for mikroelektronikk wikitext text/x-wiki [[Category:Mikroelektronikk]] 6a9f88834be2fc317820f4d288308bd501dad335 0 478 2512 2430 2017-09-15T13:29:53Z Fli091 93 Fli091 moved page [[Testbench]] to [[Cadence Testbench]]: Renamed so its understandable which testbench its about wikitext text/x-wiki = Simulate with corner cases = To simulate with the corner cases in the fabrication process you have to add the corner files provided in the design kit. [[File:Selection_001.png|200px]] Choose "Click to add corner" "Click to add" the model files you need. Ex. The corner files for the MOS transistor in IHP130nm process is located in $IHP_TECH/tech/SG13_MOS/library/spectre/cornerMOSlv_psp.scs After adding the model files needed proceed by adding multiple corners: [[File:corner.png|400px]] The model files contains sections with the different corners. Choose sections and make sure you enable the section "tick box" and name the corner with a corresponding name: [[File:sections.png|400px]] The corners setup also makes it possible to simulate for different temperatures or design variables like VDD and transistor length. Ex. test for three different temperatures with comma as separation: -20,30,80 [[File:complete.png|400px]] [[Category:Mikroelektronikk]] 88475807ac85f18a872b99cc54d478f7a2000128 0 610 2513 2017-09-15T13:29:53Z Fli091 93 Fli091 moved page [[Testbench]] to [[Cadence Testbench]]: Renamed so its understandable which testbench its about wikitext text/x-wiki #REDIRECT [[Cadence Testbench]] 275966762fc5e206b130547b9791708b1b7d94f1 0 472 2514 2426 2017-09-15T13:30:22Z Fli091 93 Added [[Category:Integrated_Circuts]] wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to one of the mikroservers: ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2016-17/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To create a command that will do this for you try this command: echo "alias startVirtuoso='source /eda/cadence/2016-17/scripts/analog_flow.sh && cd ~/ihp/cds/ && source sh.cadence && virtuoso &'" >> ~/.bashrc Typing 'startVirtuoso' in the terminal will execute these four commands Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 2751a02e3df65a202cba25fe8112ba0429e7c45b 2528 2514 2017-10-10T14:02:41Z Fli091 93 Specified mikroserver2 or mikroserver3 (1 does not work atm) wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to server (mikroserver2 or mikroserver3): ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2016-17/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To create a command that will do this for you try this command: echo "alias startVirtuoso='source /eda/cadence/2016-17/scripts/analog_flow.sh && cd ~/ihp/cds/ && source sh.cadence && virtuoso &'" >> ~/.bashrc Typing 'startVirtuoso' in the terminal will execute these four commands Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] f6ff5b4362c533db2b072d75e151a60dc0932175 2548 2528 2017-10-30T14:19:48Z Fli091 93 Removed uneccesary bash alias and linked to the setup page instead. wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to server (mikroserver2 or mikroserver3): ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2016-17/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] 5e9e64b73ec7245fabc44880668f8936f6b7c2ef 0 460 2515 2428 2017-09-15T13:30:37Z Fli091 93 Added [[Category:Integrated_Circuts]] wikitext text/x-wiki =Cadence design with AMS 350nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process using a combination of cadence and mentor tools. Here is the outline of the analog IC design flow: 1. Schematic capture (Cadence tool) 2. Netlist extraction from schematic 3. Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) 4. Layout using Cadence 5. Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 csh source /prog/cadence/cadence_init.csh ams_cds_start Virtuoso Mixed Signal Design Environment should now start up. In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose TECH_C35B4. After successfully creating the new library, it is time to create your first design. In the log windowox, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a checkmark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: 1. Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "PRIMLIB" as library, "nmos4" (for n-type transistor) or "pmos4" (for p-type transistor) as cell and "spectreS" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. 2. To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. 3. To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). 4. To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. 5. To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. 6. To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs, choose direction and click on the schematic to place it. Create one input and one output. 7. To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. 8. To check and save the schematic, press 'x' or click the "Check and save" icon. 9. If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 10. Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== 10. Choose "Create > Test..." select the cell to simulate. 11. Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. 12. Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] 13. Choose "Simulation > Debug". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" to save your state information under whatever file namn you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should allready be connected to the right positions in the symbol generator, so press ok here also and ths symbol editor will occur. Press the red X and delete the precreated green square. Use the line tool and the circle tool to create the inverter symbol- [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 9bb212007b672b1af392340d19124011ee978389 0 555 2517 2431 2017-09-15T13:31:14Z Fli091 93 Added [[Category:Integrated_Circuts]] wikitext text/x-wiki To create a butterfly curve, for example for characterizing SRAM read and hold margins, simulate a single DC sweep (one source, one sweep) on a input. Plot both the input (shows up as a straight line for a linear DC sweep) and the output (shows up as the DC response of your circuit). Have both plots in the same subwindows. go to Axis -> Y vs Y choose the first trace, press ok. go again to Axis -> Y vs Y choose the second trace, press ok. Put both results in the same plot, and you are finished. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 6dd05796414dd41887556e2dc6bab58dc32c0de4 0 38 2518 2442 2017-09-15T13:31:28Z Fli091 93 Added [[Category:Integrated_Circuts]] wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 8f0d5a843f69ba56dc15d2bc9ab1c19114484503 2533 2518 2017-10-14T14:15:27Z Fli091 93 Added link to setup of mikroservers wikitext text/x-wiki =Analog IC design flow using Cadence from basics (Schematic capture, Netlist extraction, Simulating using ELDO, Layout, Signoff Layout)= [[ TSMC 130nm process ]] [[ IHP 130nm process ]] [[ AMS 350nm process ]] = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[MikroserverSetup]] - setup for easy connection to the mikroservers and Cadence Virtuoso [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 61e86fa1e9fb2c49214cceb213bbc99b4ee2f0b3 2542 2533 2017-10-18T10:37:51Z Fli091 93 Some text to the different IC processes wikitext text/x-wiki = IC design flow using Cadence = We have access to several silicon technologies from different foundries * 130nm CMOS process from Taiwan Semiconductor Manufacturing: '''[[ TSMC 130nm process ]]''' * 130nm SiGe process from Innovations for High Performance Microelectronics: '''[[ IHP 130nm process ]]''' * 350nm CMOS process from Austria Mikro Systeme: '''[[ AMS 350nm process ]]''' = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[MikroserverSetup]] - setup for easy connection to the mikroservers and Cadence Virtuoso [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 9e102806f8eaaddfa1bc8a9ed3908a7b7815e844 0 415 2519 2440 2017-09-15T13:31:42Z Fli091 93 Added [[Category:Integrated_Circuts]] wikitext text/x-wiki = New single script install = Edit the europractice_installer.sh and change INST_DIR=/eda to INST_DIR=/prog (ignore the warning of changing install paths){{-}} Run "source europractice_installer.sh" and wait until done.{{-}} Check in the /prog/cadence/20xx-xx/script folder if there is a IC, VIPCAT and ASSURA script in there, if not modify the release versions and add the following snippet in a file called cadence_missing.csh <source lang="tcl"> setenv YEAR 2014-15 setenv $CDS_INST /prog/cadence/$YEAR/RHELx86 setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_OVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_VIPCAT $CDS_INST/VIPCAT_11.30.029_UVM setenv PATH "${PATH}:${CDS_VIPCAT}/tools/bin" if ( $?SPECMAN_PATH == 0) then setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages" else setenv SPECMAN_PATH "${CDS_VIPCAT}/utils:${CDS_VIPCAT}/packages:${SPECMAN_PATH}" endif alias help_cds_vipcat '$CDS_VIPCAT/tools/bin/cdnshelp &' # setenv CDS_ASSURA $CDS_INST/ASSURA_04.14.111_IC616OA setenv ASSURAHOME $CDS_ASSURA #the following line might be completely redundant setenv SUBSTRATESTORMHOME $ASSURAHOME # For Assura-RF setenv LANG C setenv PATH "${PATH}:${CDS_ASSURA}/tools/bin" setenv PATH "${PATH}:${CDS_ASSURA}/tools/assura/bin" setenv PATH "${PATH}:${SUBSTRATESTORMHOME}/bin" setenv ASSURA_AUTO_64BIT ALL alias help_cds_assura '$CDS_ASSURA/tools/bin/cdnshelp &' # assura setenv CDS_IC $CDS_INST/IC_6.1.6.080 # This line is required by the some design kits... setenv CDSDIR $CDS_IC # When using ADE set netlisting mode to analog ("dfIIconfig.pdf"), p16. setenv CDS_Netlisting_Mode Analog setenv MG_ENABLE_PTOT true # Required for tutorial material and cadence libraries (eg analogLib) setenv CDSHOME $CDS_IC setenv CDS_USE_PALETTE setenv PATH "${PATH}:${CDS_IC}/tools/bin" setenv PATH "${PATH}:${CDS_IC}/tools/dfII/bin" alias help_cds_ic '$CDS_IC/tools/bin/cdnshelp &' </source> Run the following to generate the startup script <source lang="tcl"> setenv YEAR 2014-15 # Fix path sed -i 's/eda/prog/g' /prog/cadence/$YEAR/scripts/*.csh # Fix non existent manpath sed -i 's/setenv MANPATH/#setenv MANPATH/g' /prog/cadence/$YEAR/scripts/*.csh chmod +x /prog/cadence/$YEAR/scripts/*.csh # Add all scripts to one fil ls /prog/cadence/$YEAR/scripts/*.csh > /prog/cadence/cadence_$YEAR\_init.csh # Add source to each line sed -i -e 's/^/source /' /prog/cadence/cadence_$YEAR\_init.csh echo 'source /prog/cadence/eda_general_init.csh' >> /prog/cadence/cadence_$YEAR\_init.csh chmod +x /prog/cadence/cadence_$YEAR\_init.csh ln -s /prog/cadence/cadence_$YEAR\_init.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh </source> The content of eda_general_init.csh is <source lang="tcl"> setenv CDS_LIC_FILE 5280@vlsi.ift.uib.no setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' </source> Run checksys.sh script given at end of this page. = Old install method= == Update install manager == Always update install manager if a newer exists or else installations may fail. cd /prog/cadence/ mkdir iscape tar zxvf /prog/download/download.msc.rl.ac.uk/Cadence/2012_2013/ISCAPE/lnx86/iscape_VERSION == Extract downloaded files == cd /prog/cadence/ mkdir download cd download find /prog/download/download.msc.rl.ac.uk/Cadence/ -name '*.tar' | xargs -l tar xvf == Run install manager == /prog/cadence/iscape/iscape/bin/iscape.sh& == configure install manager == preferences -> directories{{-}} Set default install directory to{{-}} /prog/cadence == install/update program with install manager == For new installs, follow the install instructions provided by europractice in addition to the tips from this guide. Correct directory naming reduces the amount of editing of the settings file later. * Press the icon which has the text "local directory/media install" * Select browse and navigate to the directory containing the install files and select the CDROM1 folder. *Check that there isn't a slash at the end of the path. The program doesn't search recursively. fex: /prog/cadence/unpacked/ASSURA04.12.020-5141_lnx86.Hotfix/CDROM1 *You don't need to install all updates recursively, select only the latest hotfix and the install will ask for the path to the base install when it is needed. If there are no hotfixes, install the base install. *Select the correct path to install to, keep the existing naming convention. *If a window opens with "Welcome to OpenAccess.....", just press enter and then 'n' and then enter again. *If a window opens which asks about configuring the license server, press n. *When the install is finished and you are back in the result list, you need to press the small underlined cancel text to change the path. *To make make less changes to the environment script later run this command and use the provided paths in the installation. The CDS_INST path will be changed later. cat /prog/download/download.msc.rl.ac.uk/Cadence/2013_2014/cadence_ic_2013.csh | grep CDS_INST == Package specifics == === INCISIVE === When doing a full install, INCISIVE needs to be installed first as it is required by IC. Press cancel when the ARM license file dialog shows. === ASSURA === There are two versions ASSURA*-615 and ASSURA*-5141. 5141 is for compability with IC5 (CDB). 61 is for use with IC6 (OA). === VIPCAT === Choose UVM as the packet to install for IP verification == Configuration == If a new install, then copy the template script called "cadence_ic_20xx.csh" from the download folder to the /prog/cadence folder. Line references following will be based on the 2012 release of the file. Check that actual folder names are correct. *24 - Set correct license server at line *27 - Set CDS_INST to /prog/candence *37 - Set ALTOS path to /ALTOS/altos_rel3.2p3 *57 - Set ASSURA path to /ASSURA_4.12_CDB if using IC5, /ASSURA_4.12_OA if using IC6 *72/74 - Comment/uncomment line according to IC version *83 - Set to correct MVS folder (correct according to install instructions) *110 - Set to correct IC6 folder (correct according to install instructions) *151 - Set to correct ICC folder (correct according to install instructions) *188 - Set PVE path to /PVE_11.12HF106 *213 - Set Conformal path to /CONFORMAL_11.10 *229 - Set to correct RCL folder (correct according to install instructions) *243 - Set EDI path to /EDI_11.1 *258 - Set to correct ET folder (correct according to install instructions) *274 - Set to correct ETS folder (correct according to install instructions) *293 - Set MMSIM path to /MMSIM_11.10 *315 - Set INCISIVE path to /INCISIVE_12.1 *387 - Set VIPCAT path to /VIPCAT_11.3.014 *411 - Set CTOS path to /CTOS_12.1 If you correctly set the directories like specified above you can skip editing the paths to the specific programs and only change the one for CDS_INT. Include these lines at the bottom setenv AMS_DIR /path/to/amslib setenv TSMC_DIR /path/to/tsmc setenv PATH "${PATH}:${AMS_DIR}/cds/bin" setenv CDS_BIND_TMP_DD true setenv IUSDIR $CDS_INCV alias ams_cds_start 'setenv AMS;ams_cds -tech c35b4 -nologo' alias tsmc_cds_start 'unsetenv AMS;virtuoso &' Save file as cadence_ic_20xx_uib.csh and add/update the symlink csh chmod +x /prog/cadence/cadence_ic_20xx_uib.csh ln -s /prog/cadence/cadence_ic_20xx_uib.csh /prog/cadence/cadence_init.csh source /prog/cadence/cadence_init.csh Run lmstat to check that it is possible to connect to the license server lmstat -c 5280@<your licenceserver> Both cdslmd and altosda should be listed as up. Run the checksys.sh script listed below to check for any missing dependencies and to set up any missing tools links. In case the scipt gives an error like <source lang=text> Configuration checks failed, status is: FAIL checkSysConf cannot reliably parse your systems /etc/redhat-release file It would appear that the file is non-standard and does not contain release information in the standard readable format. The contents of your /etc/redhat-release is listed below between <RELEASE_FILE> tags. A 'correct' release file should have only one line of content, containing version information in a standard format. <RELEASE_FILE> Red Hat Enterprise Linux Server release 5.9 (Tikanga) </RELEASE_FILE> Please check/correct your /etc/redhat-release file and try again. There is no OEM datafile for -r for the Linux platform. Valid OEM images are : foreach: No match. </source> then the OS is probably newer than checkSysConf used, copy a newer version from another program folder. If you then get <source lang=text> This operating system version '5.0WS' is not supported If you believe you are running a supported OS then check that the OS version directory exists in the data directory: /<path to cadence>/ICC_11.2.41/share/patchData/Linux/x86_64 </source> Then check the version in the aforementioned folder and the text file inside it. Copy the .cdsinit script below to the folder /prog/cadence/IC_6.X.X.X/tools/dfII/local == Scripts == ===Checksys.sh=== Usefull for setting up missing tools folders and checking that all dependencies are installed <source lang="bash"> #!/bin/bash # # Script for setting up tools folders and checking dependencies # By Arild Velure 2014 # if ( [ -z "$CDS_INST" ] && [ -z "$CDS_TOP" ] ) then echo "Please run environment script first" exit 1 fi # Add new modules if needed #2012 #cds_paths=( $CDS_ASSURA $CDS_MVS $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $RC_PATH $CDS_SOCE #$CDS_ET $CDS_ETS $CDS_MMSIM $incisiv_dir $CDS_VIPCAT $CTOS_ROOT ) #2013 cds_paths=( $ALTOSHOME $CDS_ASSURA $CDS_IC $CDS_ICC $CDS_PVE $CDS_CONFORMAL $CDS_RC $CDS_EDI $CDS_ET $CDS_ETS $CDS_MMSIM $CDS_INCV $CDS_VIPCAT $CTOS_ROOT) # CTOS_ROOT doesn't seem to have a checksysconf #2014 cds_paths=( $CDS_ASSURA $CDS_CONFORMAL $CTOS_ROOT $CDS_EDI $CDS_ET $CDS_EXT $CDS_IC $CDS_INCV $ALTOSHOME $CDS_MMSIM $CDS_MVS $CDS_PVS $CDS_RC $CDS_SSV $CDS_VIPCAT ) # CDS_ASSURA CDS_IC and CDS_VIPCAT needs manual script if [ -e ./problems.txt ] then rm ./problems.txt fi # Some installers forget to link the tools folder to the tools.lnx86 # Creat links so we don't need to edit and check settings file for i in "${cds_paths[@]}" do if [ ! -e $i ] then echo "Can't find path $i is it installed?" continue fi if [ ! -e $i/tools ] then if [ -e $i/tools.lnx86 ] then ln -s tools.lnx86 $i/tools fi fi # Run checksys to check that system is properly installed echo "Checking $i" if [ ! -e $i/tools/bin/checkSysConf ] then echo "checkSysConf not found" continue fi # You need to specifically mention the name of the release to test for. # Next line parses the output and grabs all lines which starts with a space and contains # some characters, which should only be release names, and puts them in an array proglist=($($i/tools/bin/checkSysConf -r | egrep '^ +\w')) # If it returns empty it propably didn't find a supported OS version if [ ${#proglist[@]} = 0 ] then $i/tools/bin/checkSysConf -r >> problems.txt echo "FAIL, couldn't find releasename" fi for a in "${proglist[@]}" do echo "Prog version $a" result=$($i/tools/bin/checkSysConf $a -q) echo "$result" if [ "$result" = "FAIL" ] then #Something failed, run again with verbosity $i/tools/bin/checkSysConf $a >> problems.txt fi done done if [ -e ./problems.txt ] then echo "Missing modules:" cat ./problems.txt | grep FAIL fi </source> ===.cdsinit=== <source lang="autohotkey"> ; AMS runs a script before starting virtuoso which creates a local .cdsinit in the current folder ; load the local .cdsinit if the program was started with the variable AMS set else load TSMC settings if(getShellEnvVar("AMS") then loadi("./.cdsinit") else ;if( ddIsId( ddGetObj( "tsmc13rf" ) ) then printf("********************************************\n") printf(" Starting TSMC 130nm \n") printf("********************************************\n") ddCreateLib( "tsmc13rf" strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf")) loadi(strcat(getShellEnvVar("TSMC_DIR") "/tsmc13rf/libInit.il")) ) </source> == Linux packages that might be required == *openmotif22 *libXp *compat-readline43 *tk *ksh *sysstat [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 59f57c3ffbc7ad2ae940c9e792fd4b9663da7d4e 0 461 2520 2427 2017-09-15T13:31:55Z Fli091 93 Added [[Category:Integrated_Circuts]] wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 source /eda/cadence/cadence_init.sh First time you should add the following line to your cds.lib file before starting the design environment. If the ~/cds.lib doesn't exist, just create it. DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf Virtuoso Mixed Signal Design Environment is started by issuing this command: tsmc_cds_start In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. # Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] # Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] d5a4504b3fa21022f2bda37d617e35c0f6f7dd3b 2530 2520 2017-10-13T07:04:38Z Fli091 93 Put "first" in bold and added command to echo define into cds.lib wikitext text/x-wiki =Cadence design with TSMC 130nm process= ==Starting up== This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ssh -X mikroserver2 source /eda/cadence/cadence_init.sh '''First''' time you should add the following line to your cds.lib file before starting the design environment. If the ~/cds.lib doesn't exist, just create it. echo "DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf" > cds.lib Virtuoso Mixed Signal Design Environment is started by issuing this command: tsmc_cds_start In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. # Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] # Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] dd4612fbf2191d12203d8675b48bbc5a1380c824 2531 2530 2017-10-13T10:00:24Z Fli091 93 Updated the setup. Now it works! wikitext text/x-wiki =Cadence design with TSMC 130nm process= This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ==Setup of Cadence== To start virtuoso one must first connect to mikroserver3 ssh -X mikroserver3 '''First''' time you should add the following line to your cds.lib-file by running this command: mkdir ~/tsmc echo "DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf" > ~/tsmc/cds.lib Then ('''each time''') run these commands to set up Cadence source /eda/cadence/2016-17/scripts/analog_flow.sh source /eda/cadence/eda_general_init.sh Virtuoso Mixed Signal Design Environment is started by issuing this command: virtuoso & === Troubleshooting === * Make sure you source the script from the correct year. I.e 2016-17 and not 2015-16 * Make sure you are connected the the right mikroserver * Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/tsmc/') == Getting started == In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. # Then open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. ==Simulating the design== # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] # Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 93aecfaabfa864c9534277c66ebcb9f580e51a9c 0 466 2521 2108 2017-09-15T13:32:07Z Fli091 93 Added [[Category:Integrated_Circuts]] wikitext text/x-wiki This script can be used to print the operating point parameters of all transistors in your design. Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a Debug Test with DC analysis: [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> The results file can also be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 4fe5983fe4c21163bcf52f47b2fa098fc9682097 2546 2521 2017-10-23T14:53:53Z Fli091 93 Added sed command to convert transistors.csv wikitext text/x-wiki = DC operating parameters from simulation = This script can be used to print the operating point parameters of all transistors in your design. Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a Debug Test with DC analysis: [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> The results file can also be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] == Importing the data into LibreOffice == To use transistors.csv one has to get rid of the postfixes for the SI units generated from Virtuoso (m, f, K etc). To do this navigate to the folder with the transistors.csv and type this command: sed -e 's/\([0-9]\+\)m/\1E-3/g' -e 's/\([0-9]\+\)u/\1E-6/g' -e 's/\([0-9]\+\)n/\1E-9/g' -e 's/\([0-9]\+\)p/\1E-12/g' -e 's/\([0-9]\+\)f/\1E-15/g' -e 's/\([0-9]\+\)a/\1E-18/g' -e 's/\([0-9]\+\)z/\1E-21/g' -e 's/\([0-9]\+\)y/\1E-24/g' -e 's/\([0-9]\+\)K/\1E+3/g' -e 's/\([0-9]\+\)M/\1E+6/g' -e 's/\([0-9]\+\)G/\1E+9/g' -e 's/\([0-9]\+\)T/\1E+12/g' transistors.csv > transistors_fixed.csv That converts transitors.csv to transistors_fixed.csv where all the SI-symbols has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 875ba28140c49b0ade1e613595b2541103f89759 2547 2546 2017-10-26T19:44:30Z Fli091 93 Added a script and description to get the file out from mikroserver and convert it to useable data wikitext text/x-wiki = DC operating parameters from simulation = This script can be used to print the operating point parameters of all transistors in your design. == Get the DC operating points from a previous simulation == Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a Debug Test with DC analysis: [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] == Copy the file to your computer and convert the values == After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from mikroserver to another computer try this: Create a file named "Makefile" and put this into it: all: get fix clean get : scp fli091@mikroserver3.ift.uib.no:~/tsmc/transistors.csv ~/transistors_raw.csv fix : sed -e 's/\([0-9]\+\)m/\1E-3/g' -e 's/\([0-9]\+\)u/\1E-6/g' -e 's/\([0-9]\+\)n/\1E-9/g' -e 's/\([0-9]\+\)p/\1E-12/g' -e 's/\([0-9]\+\)f/\1E-15/g' -e 's/\([0-9]\+\)a/\1E-18/g' -e 's/\([0-9]\+\)z/\1E-21/g' -e 's/\([0-9]\+\)y/\1E-24/g' -e 's/\([0-9]\+\)K/\1E+3/g' -e 's/\([0-9]\+\)M/\1E+6/g' -e 's/\([0-9]\+\)G/\1E+9/g' -e 's/\([0-9]\+\)T/\1E+12/g' transistors_raw.csv > transistors.csv clean: rm transistors_raw.csv Modify the scp-command to use * The username(and not fli091) in the scp-command * change mikroserver if you are not using mikroserver3. * change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/ * change the local folder where you want your copy to be placed, default is /home/$user/ A short explanation of the Makefile * The get-target gets the file from mikroserver3 and copies it to your computer in the root of your homefolder * The fix-target converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice * The clean-target just removes the not-fixed copy Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder. == Open the file in Libre Office == The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] == Troubleshooting == For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]] [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 140740aff82106513fc65590709b135043704d19 2554 2547 2017-11-01T12:48:38Z Fli091 93 Remember to check the box with "Save DC Operating Point" ! wikitext text/x-wiki = DC operating parameters from simulation = This script can be used to print the operating point parameters of all transistors in your design. == Get the DC operating points from a previous simulation == Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a test with DC analysis, and remember to check the box with "Save DC Operating Point" : [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] == Copy the file to your computer and convert the values == After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from mikroserver to another computer try this: Create a file named "Makefile" and put this into it: all: get fix clean get : scp fli091@mikroserver3.ift.uib.no:~/tsmc/transistors.csv ~/transistors_raw.csv fix : sed -e 's/\([0-9]\+\)m/\1E-3/g' -e 's/\([0-9]\+\)u/\1E-6/g' -e 's/\([0-9]\+\)n/\1E-9/g' -e 's/\([0-9]\+\)p/\1E-12/g' -e 's/\([0-9]\+\)f/\1E-15/g' -e 's/\([0-9]\+\)a/\1E-18/g' -e 's/\([0-9]\+\)z/\1E-21/g' -e 's/\([0-9]\+\)y/\1E-24/g' -e 's/\([0-9]\+\)K/\1E+3/g' -e 's/\([0-9]\+\)M/\1E+6/g' -e 's/\([0-9]\+\)G/\1E+9/g' -e 's/\([0-9]\+\)T/\1E+12/g' transistors_raw.csv > transistors.csv clean: rm transistors_raw.csv Modify the scp-command to use * The username(and not fli091) in the scp-command * change mikroserver if you are not using mikroserver3. * change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/ * change the local folder where you want your copy to be placed, default is /home/$user/ A short explanation of the Makefile * The get-target gets the file from mikroserver3 and copies it to your computer in the root of your homefolder * The fix-target converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice * The clean-target just removes the not-fixed copy Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder. == Open the file in Libre Office == The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] == Troubleshooting == For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]] [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] e4c304b60dc779c43bb6ecf712f8f575e0a58406 2555 2554 2017-11-01T12:51:08Z Fli091 93 Commented the makefile wikitext text/x-wiki = DC operating parameters from simulation = This script can be used to print the operating point parameters of all transistors in your design. == Get the DC operating points from a previous simulation == Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a test with DC analysis, and remember to check the box with "Save DC Operating Point" : [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] == Copy the file to your computer and convert the values == After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from mikroserver to another computer try this: Create a file named "Makefile" and put this into it: # target that is the first (and default) and does all the stuff below all: get fix clean # gets the file from mikroserver3 and copies it to your computer in the root of your homefolder get : scp fli091@mikroserver3.ift.uib.no:~/tsmc/transistors.csv ~/transistors_raw.csv # converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice fix : sed -e 's/\([0-9]\+\)m/\1E-3/g' -e 's/\([0-9]\+\)u/\1E-6/g' -e 's/\([0-9]\+\)n/\1E-9/g' -e 's/\([0-9]\+\)p/\1E-12/g' -e 's/\([0-9]\+\)f/\1E-15/g' -e 's/\([0-9]\+\)a/\1E-18/g' -e 's/\([0-9]\+\)z/\1E-21/g' -e 's/\([0-9]\+\)y/\1E-24/g' -e 's/\([0-9]\+\)K/\1E+3/g' -e 's/\([0-9]\+\)M/\1E+6/g' -e 's/\([0-9]\+\)G/\1E+9/g' -e 's/\([0-9]\+\)T/\1E+12/g' transistors_raw.csv > transistors.csv # removes the not-fixed copy clean: rm transistors_raw.csv Modify the scp-command to use * The username(and not fli091) in the scp-command * change mikroserver if you are not using mikroserver3. * change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/ * change the local folder where you want your copy to be placed, default is /home/$user/ Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder. == Open the file in Libre Office == The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] == Troubleshooting == For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]] [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] c18149712f650c23ccc7951536a92883576a4971 2556 2555 2017-11-11T15:21:01Z Fli091 93 Link to another guide wikitext text/x-wiki = DC operating parameters from simulation = This script can be used to print the operating point parameters of all transistors in your design and save them to a file. If you just want to view them in Virtusoso have a look at this guide instead: [[DCoperatingparameters]] == Get the DC operating points from a previous simulation == Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a test with DC analysis, and remember to check the box with "Save DC Operating Point" : [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] == Copy the file to your computer and convert the values == After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from mikroserver to another computer try this: Create a file named "Makefile" and put this into it: # target that is the first (and default) and does all the stuff below all: get fix clean # gets the file from mikroserver3 and copies it to your computer in the root of your homefolder get : scp fli091@mikroserver3.ift.uib.no:~/tsmc/transistors.csv ~/transistors_raw.csv # converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice fix : sed -e 's/\([0-9]\+\)m/\1E-3/g' -e 's/\([0-9]\+\)u/\1E-6/g' -e 's/\([0-9]\+\)n/\1E-9/g' -e 's/\([0-9]\+\)p/\1E-12/g' -e 's/\([0-9]\+\)f/\1E-15/g' -e 's/\([0-9]\+\)a/\1E-18/g' -e 's/\([0-9]\+\)z/\1E-21/g' -e 's/\([0-9]\+\)y/\1E-24/g' -e 's/\([0-9]\+\)K/\1E+3/g' -e 's/\([0-9]\+\)M/\1E+6/g' -e 's/\([0-9]\+\)G/\1E+9/g' -e 's/\([0-9]\+\)T/\1E+12/g' transistors_raw.csv > transistors.csv # removes the not-fixed copy clean: rm transistors_raw.csv Modify the scp-command to use * The username(and not fli091) in the scp-command * change mikroserver if you are not using mikroserver3. * change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/ * change the local folder where you want your copy to be placed, default is /home/$user/ Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder. == Open the file in Libre Office == The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] == Troubleshooting == For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]] [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 1788b96760757bfede593cf16b901158d6ade31e 14 611 2522 2017-09-15T13:32:50Z Fli091 93 Created mikroelektronikk subcategory integrated_circuits wikitext text/x-wiki [[Category:Mikroelektronikk]] 66d42b439a8971cd09a833910031be094c8fdcb6 0 234 2523 2422 2017-09-18T08:50:24Z Nfyst 67 /* Defended Master theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. (can be found via 'Bibsys') === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at ps = 13 TeV * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] 55f0d852a6590f1ad1b5a64bd25d7387e5bfdaf3 2525 2523 2017-09-18T10:34:06Z Nfyst 67 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. (can be found via 'Bibsys') === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] ef0b252c4cee52bd4a3e780578124a20e50a4ff1 2526 2525 2017-09-23T03:05:22Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. (can be found via 'Bibsys') === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 73ee3a9057ced9d9bd80aa85da9167f29e70c13f 2537 2526 2017-10-17T10:27:48Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. (can be found via 'Bibsys') === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 9be99cd5e47025c9c282f295aa5e5cd78e3dae3c 6 612 2524 2017-09-18T10:32:11Z Nfyst 67 MSc thesis, Are Træaet wikitext text/x-wiki MSc thesis, Are Træaet cabbec68ec1b5d872dc206edb43e94827b7d31ca 6 613 2527 2017-09-23T03:05:57Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 139 2529 2372 2017-10-11T15:15:01Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics). This includes 2016-2017 Bergen-Oslo meetings. https://indico.cern.ch/category/7495/ Old and not updated Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here (I still keep it for a while): https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2018 === "Spatind conference", Nordic Bi-annual conference in High Energy Physics, 2-8 January 2018 [https://indico.cern.ch/event/666278/ web page] Please register ASAP. you are (most probably) funded by the HEPP project. === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 5e547c9244de433db695c02432995aa983e586e7 2544 2529 2017-10-19T03:04:19Z Nfyal 26 /* 2018 */ wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics). This includes 2016-2017 Bergen-Oslo meetings. https://indico.cern.ch/category/7495/ Old and not updated Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here (I still keep it for a while): https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2018 === "Spatind conference", Nordic Bi-annual conference in High Energy Physics, 2-8 January 2018 [https://indico.cern.ch/event/666278/ web page] Please register ASAP. you are (most probably) funded by the HEPP project. * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] cef19cf3db59c49840395935782c06c39f4b8b28 0 614 2532 2017-10-14T14:14:14Z Fli091 93 created page wikitext text/x-wiki = Setup of connection to mikroservers and cadence virtuoso = This setup will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or hostnames The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your usename ssh-copy-id USENAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso'&"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso to start cadence virutoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the USERNAME with your usename, i.e "fli091" 6e46bd80252ffa9d01ff199979cc2655eacd7858 2534 2532 2017-10-14T14:15:37Z Fli091 93 Added [[Category:Mikroelektronikk]] wikitext text/x-wiki = Setup of connection to mikroservers and cadence virtuoso = This setup will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or hostnames The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your usename ssh-copy-id USENAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso'&"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso to start cadence virutoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 1a7c4c281dc416f3c4e9bf6422eba98106ff37e7 2535 2534 2017-10-14T14:27:57Z Fli091 93 Fixed typo wikitext text/x-wiki = Setup of connection to mikroservers and cadence virtuoso = This setup will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or hostnames The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your usename ssh-copy-id USENAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso'&"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] e12534123a073e6bda4eeb2fb0d1a880cd65fc8a 2539 2535 2017-10-18T10:19:32Z Fli091 93 TSMC warning and fixed typos wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso'&"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 6b2caad6c1009c224531f1c141568cbe7dc26772 2540 2539 2017-10-18T10:31:23Z Fli091 93 Sourcing the script for IPH in .bashrc wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup source ~/ihp/cds/sh.cadence Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso'&"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 7ccf0a071260fcbd54b09a44f531728e400cf08c 2541 2540 2017-10-18T10:32:14Z Fli091 93 Actually sourcing the IHPscript too wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso'&"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] d104a2d9bb1ad2d4e436aa43e0fbd090e5a6db36 2549 2541 2017-10-30T14:21:23Z Fli091 93 Added a alias for launching IHP directly as the TSMCcommand and renamed the aliases from "virtuoso" to "virtuoso_tsmc" wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 58e09e4ef35c88230cd69c4aa69143b632ac1176 2550 2549 2017-10-31T08:43:56Z Fli091 93 The aliases needed the &. Added it again wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no Do the following: * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no * Set up aliases for the connections in your terminal echo "alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no'" >> ~/.bashrc echo "alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc * source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] ebbc40964e8c6a510cf41170206f0c0f4679592b 2552 2550 2017-10-31T10:51:33Z Fli091 93 Added description to add mikroserver as a folder wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no == SSH key == * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no == Connection aliases == For ease of use set up aliases for the connections in your terminal. Open .bashrc in a text editor (vim / nano) and type in this alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no' alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no' alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no' Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc == Automatic sourcing == Source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc == Commands to run virtuoso remotely == Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3.ift.uib.no/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 7c1b13838bf2b82ed5f72425e186028d20aa7571 2553 2552 2017-10-31T10:53:20Z Fli091 93 How to bookmark the mikroserver folder-connection wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no == SSH key == * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no == Connection aliases == For ease of use set up aliases for the connections in your terminal. Open .bashrc in a text editor (vim / nano) and type in this alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no' alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no' alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no' Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc == Automatic sourcing == Source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc == Commands to run virtuoso remotely == Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3.ift.uib.no/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 8afe4362f2ba60cba6ef59ee94b2e496e26971a8 3 615 2536 2017-10-14T14:29:44Z Fli091 93 Kill the red links wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 616 2538 2017-10-17T10:29:02Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 137 2543 2423 2017-10-19T03:03:13Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] f69afdf53663112d1f1b9e9445cdb1d3411cbfd0 0 249 2545 942 2017-10-23T09:00:21Z Fli091 93 Added categories / [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] wikitext text/x-wiki ==Estimere delay av en og to invertere i serie== 1. Høyre klikk i cell view i library vinduet og velg "New Cell View". 2. Kall det delay, velg schematic i dropdown menyen og trykk finish. 3. Trykk "Add instance" på venstre side, velg inverteren du nettop laget og trykk OK. 4. Lag tre invertere i serie ved å merke den du la til og trykke C på tastaturet. 5. Velg "Add->Source", merk av DC og sett spenningen til 3.3V 6. Trykk på "HIT-Kit Utilities->AMS Library" på fil-menyen. 7. Legg til VDD og GND. De ligger under "etc->cell power->vdd_g" for VDD og "etc->cell power->gnda_g" for GND 8. Legg til puls kilde ved å velge "Add->Source", merk av PULSE og sett verdiene som vist på bildet. [[File:pulse.jpg|400px]] 9. Legg til kabler som på bildet under. 10. Sett navn på nettet mellom første og andre inverter ved å velge den og trykke på "Net name", kall den out1. Kall nettet mellom inverter 2 og 3 for out2. Kall nettet etter kilden for in. [[File:skjema.jpg|600px]] 11. Trykk "Check & Save". Trykk "HIT-Kit Utilities->Create Viewpoint", trykk navigator og finn frem til mappen der prosjektet dit er i, $navn_på_library/default.group/logic.views/delay Ikke åpne delay mappen, bare merk den. 12. Trykk "Enter simulation mode" og trykk ok på vinduet som kommer opp. 13. Velg "Session->netlister" på høyre side og sjekk at det står gnda i "Set Node 0" feltet. 14. Velg Analysis på høyre side, hak av for transient(ta vekk AC), trykk på setup ved siden av transient og sett stop time til 3n og max step time til 10p. 15. Hold nede CTRL og velg in, out1 og out2 nettene. Trykk så på "Wave outputs" på høyre side. 16. Velg alle nettene under objects, velg TRAN under analysis og trykk på knappen med en tegning av ett ark med et pluss tegn på, trykk krysset for å lukke. 17. Velg "HIT-Kit Utilities->Set simulation models", trykk ok på vinduet. 18. Trykk "Run ELDO" og når det er ferdig å flytte på seg i tekstruten som kommer opp kan du trykke "View waves" 19. Ekspander tran mappen på venstre side, merk alle tre plottene med ctrl, høyreklikk og velg plot stacked. 20. Trykk CTRL+M for å få opp measurement tool. Velg Time domain under measurement. Trykk på V(IN) på plottet i bakgrunnen(uten å lukke measurement tool) og trykk på knappen med bilde av en graf på på linjen til #1. Trykk så på V(Out1) og på knappen til #2. Under Edge trigger trykker du på oppadgående flanke, under edge relationship velger du inverting, hak av for find closest reference edge og trykk apply. Skift edge trigger til nedadgående og trykk apply igjen. 21. Gjør det samme som over men velg V(out2) istedet for V(out1) og skift edge relationship til non-inverting. 22. Du får nå opp tpdf og tpdr på grafen. [[File:graf.jpg]] == Andre tips til oppgaven == Fungerer ikke dynamiske eller statiske vippen? Sjekk at du har plassert clock og clock invers på riktig inngang/riktig transistor, de skifter side fra første til andre ledd. Prøv å bruke Cgs til kalkulering av delay om du ikke får noe fornuftig svar. Når du skal lage clk invers så er det en fordel å ikke bruke en inverter, lag to pulskilder der den ene har et delay like langt som en pulsbredde, ellers så får du et ekstra delay på klokken aka clock skew. Tristate bufferet kan regnes som parasitisk, mao tilfører den 8C på inngangen og utgangen. Transmition gaten kobles opp med source mot kilden. Kobl bulk for nmos til gnd og pmos til VDD. Blir utsignalet bare bølgete rundt VDD så har du for kort pulslengde, hold deg over 2ns. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] bca677cd300bca1931b43717cf3c6605bc5ec63c 6 617 2551 2017-10-31T10:41:15Z Fli091 93 Screenshot showing where to click to add a folder on a server wikitext text/x-wiki Screenshot showing where to click to add a folder on a server 12bc5afb1843290b410cc5a810b2ce0e68c3f799 6 618 2557 2017-11-11T15:51:15Z Fli091 93 Picture showing Cadence Virtuso with a pmos with DC operating parameters showing wikitext text/x-wiki Picture showing Cadence Virtuso with a pmos with DC operating parameters showing 5e1098c469da350523cb47e5ef580398d20afed8 6 619 2558 2017-11-11T15:53:36Z Fli091 93 Picture showing the location of the annotation menu in Cadence Virtuso wikitext text/x-wiki Picture showing the location of the annotation menu in Cadence Virtuso 5805315f98087abb0b7555448a17c28de097411c 6 620 2559 2017-11-11T15:54:34Z Fli091 93 Picture showing the annotation setup in Cadence Virtuoso wikitext text/x-wiki Picture showing the annotation setup in Cadence Virtuoso e416492b96f6b1debb6b9d82d293cd0a9ca9d05f 0 621 2560 2017-11-11T15:59:04Z Fli091 93 Created a guide to dc operating parameters in cadence virtuoso wikitext text/x-wiki = Show DC operating parameters = This guide will show you how to show DC operating parameters like gm, R_{out} V_{th} etc for all your transistors in a Cadence schematic. If you just want to save all parameters to a file have a look at this guide instead: [[Transistor operating point printer]] == Steps == # Create your circuit in a schematic # Set up a DC simulation, check the "save operating point"-box in the creating of the test # Go back to your schematic window and at the top-men click: # View - Annotations - DC Operating Points. This will give a default selection of parameters [[File:AnnotationMenu.png|thumbnail|right|The annotation menu]] # To chose which to view in your schematic go back to View - Annotations and at the bottom click "Setup.." # Make sure the library-drop-down is showing "tsmc13rf" (or your transistor library), choose pmos in "Cell" and leave instance to "*" if you want to change it for all transistors in your sheet. # Here you can see the list that is showing by default and three "free" cells at the rows Parameter:cdsPara(6), (7) and (8) # Double click in the column "Expression" for those rows and select the parameter you want to show (i.e region, rout, gm, gds) [[File:AnnotationSetupWindow.png|100px|thumbnail|right|The annotation setup window]] #* You might want to disable annotation of the first four rows here to hide some annotation noise # Click apply and repeat the same steps for the nmos cell [[File:PmosWithDCParameters.png|thumbnail|right|PMOS with parameters showing]] # Save this annotation set-up by clicking File - Save. Chose the default location to make it easy for yourself. (If you don't save you have to do this set-up every time you close Virtuoso) #* The next time you load your design just click View - Annotations - Setup.. and then File - Load - OK == Note == * Region 0 is cutoff * Region 1 is linear * Region 2 is saturation * Region 3 is subthreshold * Region 4 is breakdown * Type 0 is nMOS * Type 1 is pMOS [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] b3371a14debdb72335b6ed5c179f084eb05543d9 0 38 2561 2542 2017-11-11T16:08:02Z Fli091 93 Added link to another helpful thing / DCoperatingparameters wikitext text/x-wiki = IC design flow using Cadence = We have access to several silicon technologies from different foundries * 130nm CMOS process from Taiwan Semiconductor Manufacturing: '''[[ TSMC 130nm process ]]''' * 130nm SiGe process from Innovations for High Performance Microelectronics: '''[[ IHP 130nm process ]]''' * 350nm CMOS process from Austria Mikro Systeme: '''[[ AMS 350nm process ]]''' = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[MikroserverSetup]] - setup for easy connection to the mikroservers and Cadence Virtuoso [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[DCoperatingparameters]] - Guide for showing transistor operating points in the schematic [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] e340e31e16ec218063d5a08f34e831dba6ef3927 0 614 2562 2553 2017-11-14T12:10:58Z Fli091 93 Added alternative way to get your files from mikroserver wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no == SSH key == * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no == Connection aliases == For ease of use set up aliases for the connections in your terminal. Open .bashrc in a text editor (vim / nano) and type in this alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no' alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no' alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no' Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc == Automatic sourcing == Source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc == Commands to run virtuoso remotely == Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3.ift.uib.no/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/fredrik/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:~ * this will copy the file to your home folder on any UiB machine == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 175fdd8c4685449cbc30ae3fb6016b1b2bb70dbe 2563 2562 2017-11-14T12:11:21Z Fli091 93 Formatting wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no == SSH key == * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no == Connection aliases == For ease of use set up aliases for the connections in your terminal. Open .bashrc in a text editor (vim / nano) and type in this alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no' alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no' alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no' Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc == Automatic sourcing == Source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc == Commands to run virtuoso remotely == Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3.ift.uib.no/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/fredrik/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:~ * this will copy the file to your home folder on any UiB machine == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] c2fa9c275f0e4112d99c627b069ece91e802dc85 0 137 2564 2543 2017-11-20T20:46:09Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report (not the final version alas) from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] a1a676323b72991af68c249544e5ff81fa86fcab 6 622 2565 2017-11-20T20:46:55Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 623 2566 2017-11-24T08:55:58Z Hpe090 98 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 624 2567 2017-11-24T08:55:58Z Hpe090 98 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 625 2568 2017-11-24T08:55:59Z Hpe090 98 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 626 2569 2017-11-24T08:55:59Z Hpe090 98 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 627 2570 2017-11-24T08:55:59Z Hpe090 98 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 628 2571 2017-11-24T09:03:00Z Hpe090 98 Created page with "== Introduction and overview == This is a simple tutorial for GATE (Geant4) installation and usage, originally presented as a workshop for the pCT group in March 2017. # [ht..." wikitext text/x-wiki == Introduction and overview == This is a simple tutorial for GATE (Geant4) installation and usage, originally presented as a workshop for the pCT group in March 2017. # [http://geant4.in2p3.fr/spip.php?rubrique8 Geant4 and ROOT virtual machine] # [http://wiki.opengatecollaboration.org/index.php/Compilation_Instructions_V8.0 Gate installation] Agenda for the day is as follows: # An introduction to GATE macros, i.e. GATE input scripts # Setting up a simple simulation geometry in GATE using a proton bencil beam and a water phantom # Running short simulations # Examination of the GATE-output files == GATE == ''Simulations of Preclinical and Clinical Scans in Emission Tomography, Transmission Tomography and Radiation Therapy'' Geant4 is a C++ library, where an application / simulation is built by writing certain C++ classes (geometry, beam, scoring, output, physics), and compiling the binaries from where the simulations are run. Only certain modifications to the simulations can be made with the binaries, such as beam settings, certain physics settings as well as geometry objects pre-defined to be variable. GATE is an application written for Geant4. It was originally meant for PET and SPECT uses, however it is very flexible so many different kinds of detectors can be designed. To run GATE, only macro files written in the Geant4 scripting language (with some GATE specific commands) are needed to build the geometry, scoring, physics and beam. The output is also defined in the macro files, either to ASCII files or to ROOT files. In each simulation, the user has to: # define the scanner geometry # set up the physics processes # initialize the simulation # set up the detector model # define the source(s) # specify the data output format # start the acquisition === Introduction to GATE macros === Gate, just as GEANT4, is a program in which the user interface is based on scripts. To perform actions, the user must either enter commands in interactive mode, or build up macro files containing an ordered collection of commands. Each command performs a particular function, and may require one or more parameters. The Gate commands are organized following a tree structure, with respect to the function they represent. For example, all geometry-control commands start with geometry, and they will all be found under the ''/geometry/'' branch of the tree structure. When Gate is run, the '''Idle>''' prompt appears. At this stage the command interpreter is active; i.e. all the Gate commands entered will be interpreted and processed on-line. All functions in Gate can be accessed to using command lines. The geometry of the system, the description of the radioactive source(s), the physical interactions considered, etc., can be parameterized using command lines, which are translated to the Gate kernel by the command interpreter. In this way, the simulation is defined one step at a time, and the actual construction of the geometry and definition of the simulation can be seen on-line. If the effect is not as expected, the user can decide to re-adjust the desired parameter by re-entering the appropriate command on-line. Although entering commands step by step can be useful when the user is experimenting with the software or when he/she is not sure how to construct the geometry, there remains a need for storing the set of commands that led to a successful simulation. Macros are ASCII files (with '.mac' extension) in which each line contains a command or a comment. Commands are GEANT4 or Gate scripted commands; comments start with the character ' #'. Macros can be executed from within the command interpreter in Gate, or by passing it as a command-line parameter to Gate, or by calling it from another macro. A macro or set of macros must include all commands describing the different components of a simulation in the right order. Usually these components are visualization, definitions of volumes (geometry), systems, digitizer, physics, initialization, source, output and start. These steps are described in the next sections. A single simulation may be split into several macros, for instance one for the geometry, one for the physics, etc. Usually, there is a master macro which calls the more specific macros. Splitting macros allows the user to re-use one or more of these macros in several other simulations, and/or to organize the set of all commands. To execute a macro (mymacro.mac in this example) from the Linux prompt, just type : Gate mymacro.mac To execute a macro from inside the Gate environment, type after the "Idle>" prompt: Idle>/control/execute mymacro.mac And finally, to execute a macro from inside another macro, simply write in the master macro: /control/execute mymacro.mac === Setting up a simple simulation geometry in GATE using a pencil beam and a water phantom === ==== Visualization ==== First we may want to set up a visualization engine to see what's going on. This is optional, and runs in batch mode should not be visualized! Here we use the opengl visualizer OGLX, but different kinds of visualization engines are discussed in the [http://wiki.opengatecollaboration.org/index.php/Users_Guide_V7.2:Visualization GATE wiki] /vis/open OGLSX /vis/viewer/reset /vis/viewer/set/viewpointThetaPhi 60 60 /vis/viewer/zoom 1 /vis/viewer/set/style surface /vis/drawVolume /tracking/storeTrajectory 1 /vis/scene/endOfEventAction accumulate /vis/viewer/update Most of these commands are self explainatory. By using the storeTrajectory command, all particles are displayed together with the geometry. ==== Materials database ==== The default material assigned to a new volume is Air. The list of available materials is defined in the GateMaterials.db file. It's included in the Gate folder, and should be copied to the active directory. It is easy to add new materials to the file, just have a look at the file. /gate/geometry/setMaterialDatabase MyMaterialDatabase.db ==== Geometry ==== Apart from specialized geometries such as PET, SPECT, CT, the general geometry is called as ''scanner''. It must be placed within the ''world'' volume, and all parts of the detector (to be scored) be placed within the ''scanner'' volume. [[File:geometry_hiarerachy.png|400px]] To construct a simple water phantom geometry of 30x30x30 cm, use the following commands: /gate/world/geometry/setXLength 1000. cm /gate/world/geometry/setYLength 1000. cm /gate/world/geometry/setZLength 1000. cm So we've defined a world geometry of 1 m³. It must be larger than all its daughter volumes. Let's put the ''scanner'' volume inside the ''world'' volume. Since it's not already defined (the ''world'' volume was), we must insert a ''box'' object (with parameters XLength, YLength, ZLength as the side measurements of the box): /gate/world/daughters/name scanner /gate/world/daughters/insert box /gate/scanner/geometry/setXLength 100. cm /gate/scanner/geometry/setYLength 100. cm /gate/scanner/geometry/setZLength 100. cm /gate/scanner/placement/setTranslation 0 0 50. cm /gate/scanner/vis/forceWireframe Inside this scanner volume (the default material is Air): /gate/scanner/daughters/name phantom /gate/scanner/daughters/insert box /gate/phantom/geometry/setXLength 30. cm /gate/phantom/geometry/setYLength 30. cm /gate/phantom/geometry/setZLength 30. cm /gate/phantom/placement/setTranslation 0 0 -15. cm /gate/phantom/setMaterial Water /gate/phantom/vis/forceWireframe It is possible to repeat volumes. The simple method is to use a linear replicator: /gate/phantom/repeaters/insert linear /gate/phantom/linear/autoCenter false /gate/phantom/linear/setRepeatNumber 10 /gate/phantom/linear/setRepeatVector 0 0 35. cm The autoCenter command: The original volume is anchored (false), instead of the center-of-mass of all copies being centered at that position (true). ==== Sensitive Detectors ==== The scoring system in Geant4/GATE is based around ''Sensitive Detectors'' (SD). If a volume is a daughter volume (or grand-daughter, ...), it may be assigned as a SD. This process is super simple in GATE: /gate/phantom/attachCrystalSD If you want to define hierarchically repeated structures, such as layers or individually simulated pixels, they should be defined as a ''level'': /gate/scanner/level1/attach phantom /gate/scanner/level2/attach repeatedStructureWithinPhantom And now you can use the ROOT leaf ''level1ID'' and ''level2ID'' to identify the volume. ==== Physics ==== There are many physics lists to choose from in Geant4/GATE. For proton therapy and detector simulations, I most often use a combination of a low-energy-friendly hadronic list and the variable-steplength (for Bragg Peak accuracy) electromagnetic list. From the [http://geant4.cern.ch/support/physicsLists/referencePL/referencePL.shtml Geant4 reference physics webpage]: * QGSP: QGSP is the basic physics list applying the quark gluon string model for high energy interactions of protons, neutrons, pions, and Kaons and nuclei. The high energy interaction creates an exited nucleus, which is passed to the precompound model modeling the nuclear de-excitation. * QGSP_BIC: Like QGSP, but using Geant4 Binary cascade for primary protons and neutrons with energies below ~10GeV, thus replacing the use of the LEP model for protons and neutrons In comparison to the LEP model, Binary cascade better describes production of secondary particles produced in interactions of protons and neutrons with nuclei. * emstandard_opt3 designed for any applications required higher accuracy of electrons, hadrons and ion tracking without magnetic field. It is used in extended electromagnetic examples and in the QGSP_BIC_EMY reference Physics List. An overview over the different electromagnetic physics lists can be found [http://geant4.cern.ch/collaboration/working_groups/electromagnetic/physlist10.3.shtml here]. The physics list to use all of these is called ''QGSP_BIC_EMY''. It is loaded with the command /gate/physics/addPhysicsList QGSP_BIC_EMY In addition, in order to accurately represent the water in the water phantom, we define the current recommended value for the mean ionization potential for water, which is <math>75\ \mathrm{eV}</math>. This can be performed for all materials, and it will override Bragg's additivity rule. /gate/geometry/setIonisationPotential Water 75 eV ==== Initialization ==== After the geometry and physics has been set, initialize the run! /gate/run/initialize ==== Proton beam ==== /gate/source/addSource PBS PencilBeam /gate/source/PBS/setParticleType proton /gate/source/PBS/setEnergy 188.0 MeV /gate/source/PBS/setSigmaEnergy 1.0 MeV /gate/source/PBS/setPosition 0 0 -10. mm /gate/source/PBS/setSigmaX 2 mm /gate/source/PBS/setSigmaY 4 mm /gate/source/PBS/setSigmaTheta 3.3 mrad /gate/source/PBS/setSigmaPhi 3.8 mrad /gate/source/PBS/setEllipseXThetaEmittance 15 mm*mrad /gate/source/PBS/setEllipseXThetaRotationNorm negative /gate/source/PBS/setEllipseYPhiEmittance 20 mm*mrad /gate/source/PBS/setEllipseYPhiRotationNorm negative /gate/application/setTotalNumberOfPrimaries 5000 It is tricky to use this beam since all parameters need to match, so an '''alternative''' is to use a uniform General Particle Source: /gate/source/addSource uniformBeam gps /gate/source/uniformBeam/gps/particle proton /gate/source/uniformBeam/gps/ene/type Gauss /gate/source/uniformBeam/gps/ene/mono 188 MeV /gate/source/uniformBeam/gps/ene/sigma 1 MeV /gate/source/uniformBeam/gps/type Plane /gate/source/uniformBeam/gps/shape Square /gate/source/uniformBeam/gps/direction 0 0 1 /gate/source/uniformBeam/gps/halfx 0 mm /gate/source/uniformBeam/gps/halfy 0 mm /gate/source/uniformBeam/gps/centre 0 0 -1 cm /gate/application/setTotalNumberOfPrimaries 5000 ==== Output ==== For this tutorial, we will use the ROOT output. /gate/output/root/enable /gate/output/root/setFileName gate_simulation ==== Running the simulation ==== To finalize the macro file, start the randomization engine and run! /gate/random/setEngineName MersenneTwister /gate/random/setEngineSeed auto /gate/application/start === Running short simulations === To run a simulation, create a macro file with the lines as descibed above, and run it with $ Gate waterphantom.mac The terminal output describes the geometry, physics, etc. If you want the visualization to be persistent, use instead $ Gate ... [TEXT] Idle> /control/execute waterphantom.mac It is also possible to use aliases in the macro file. For example, to simplify the energy selection, substitute with the line /gate/source/PBS/setEnergy {energy} MeV and run the macro with $ Gate -a '[energy,175]' waterphantom.mac Multiple aliases can be stacked: $ Gate -a '[energy,175] [phantomsize,45]' waterphantom.mac if you have defined multiple alises in the macro file. It is sadly not possible to do calculations in the macro language, so you have to do that through bash (<code>newvalue=`echo "$oldvalue/2" | bc`</code>). === Examination of the GATE output files === The ROOT output file(s) from the simulation can be opened several ways: * By using the built-in <code>TBrowser</code> to look at scoring variable distributions * By using loading the ROOT Tree into a C++ program and looping over events (interactions) ==== Using the built-in <code>TBrowser</code> ==== The hierarchy for the files are shown in the image below: [[File:root_file_hierarchy.PNG|600px]] In Gate, the TTree is called ''Hits'', and the leaves are named after the different variables that are automatically scored: PDGEncoding - The Particle ID trackID - Track number following a mother particle parentID - The parent track's event ID. 0 if the current particle is a beam particle time - Time in simulation (for ToF in PET, etc.) edep - Deposited energy in this event / interaction stepLength - The length of the current step posX - Global X position of event posY - Global Y position of event posZ - Global Z position of event localPosX - Local (in mother volume) X position of event localPosY - Local (in mother volume) Y position of event localPosZ - Local (in mother volume) Z position of event baseID - ID of mother volume ''scanner'', == 0 if only one ''scanner'' defined level1ID - ID of 1st level of volume hierarchy level2ID - ID of 2nd level of volume hierarchy level3ID - ID of 3rd level of volume hierarchy level4ID - ID of 4th level of volume hierarchy sourcePosX - Global X position of source particle sourcePosY - Global Y position of source particle sourcePosZ - Global X position of source particle eventID - History number (important!!) volumeID - ID of current volume (useful to isolate particles in a specific part of a fully scored volume) processName - A string containing the name of the interaction type: - hIoni: Ionization by hadron - Transportation: No special interactions (usually from step limiter) - eIoni: Ionization by electron - ProtonInelastic: Inelastic nuclear interaction of proton - compt: Compton scattering - ionIoni: Ionization by ion - msc: Multiple Coulomb Scattering process - hadElastic: Elastic hadron / proton scattering An example of the distribution of eventID (in histogram form, this is the number of interactions per particle (if bin size = 1)) $ root ROOT [0] new TBrowser [[File:root.PNG|600px]] Or for the Z distribution (see the Bragg Peak) [[File:root2.PNG|600px]] ==== Opening the files in C++ ==== It is quite simple to open the generated ROOT files in a C++ program. In <code>openROOTFile.C</code>: #include <TTree.h> #include <TFile.h> using namespace std; void Run() { TFile *f = new TFile("gate_simulation.root"); TTree *tree = (TTree*) f->Get("Hits"); // The TTree in the GATE file is called ''Hits'' // Declare the variables (leafs) to be readout Float_t x,y,z,edep; Int_t eventID, parentID; // Make a connection between the declared variables and the leafs tree->SetBranchAddress("posX", &x); tree->SetBranchAddress("posY", &y); tree->SetBranchAddress("posZ", &z); tree->SetBranchAddress("edep", &edep); tree->SetBranchAddress("eventID", &eventID); tree->SetBranchAddress("parentID", &parentID); // Loop over all the entries in the tree for (Int_t i=0, i < tree->GetEntries(); ++i) { tree->GetEntry(i); if (eventID > 2) break; // To limit the output! if (parentID != 0) continue; // Only show results from primary particles printf("Primary particle with event ID %d has an interaction with %.2f MeV energy loss at (x,y,z) = (%.2f, %.2f, %.2f).\n", eventID, edep, x, y, z); } delete f; } Then you can run the program with $ root ROOT [0] .L openROOTFile.C+ // The + tells ROOT to compile the code ROOT [1] Run(); Please note that it is also possible to make a complete class to read out the root files using ROOT's <code>MakeClass</code> function. See [http://wiki.opengatecollaboration.org/index.php/Users_Guide_V7.2:Data_output#How_to_analyze_the_Root_output "How to analyze the ROOT output"]. ==== Test case: Finding the range and straggling of a proton beam ==== #include <TTree.h> #include <TH1F.h> #include <TFile.h> #include <TF1.h> using namespace std; void Run() { TFile * f = new TFile("gate_simulation.root"); TTree * tree = (TTree*) f->Get("Hits"); // The TTree in the GATE file is called ''Hits'' TH1F * rangeHistogram = new TH1F("rangeHistogram", "Stopping position for protons"; 800, 0, 400); // Histogram 1D with Float values Float_t z; Int_t eventID, parentID; Int_t lastEventID = -1; Float_t lastZ = -1; tree->SetBranchAddress("posZ", &z); tree->SetBranchAddress("eventID", &eventID); tree->SetBranchAddress("parentID", &parentID); for (Int_t i=0, i < tree->GetEntries(); ++i) { tree->GetEntry(i); if (parentID != 0) continue; // Check if this is the first event of a primary particle if (eventID != lastEventID && lastEventID >= 0) { rangeHistogram->Fill(lastZ); } // Store the current variables lastZ = z; lastEventID = eventID; } rangeHistogram->Draw(); // Make a Gaussian fit to the range TF1 * fit = new TF1("fit", "gaus"); rangeHistogram->Fit("fit", "", "", 150, 250); // Most probable values for fit is in this range, ROOT is quite sensitive to Gaussians occupying only a small part of the histogram, so give narrow fit range printf("The range of the proton beam is %.3f +- %.3f mm.\n", fit->GetParameter(1), fit->GetParameter(2)); } This time, the program will yield the following output (from a 250 MeV beam): The range of the proton beam is 378.225 mm +- 3.791 mm With the following histogram (I've added some color and a SetOptFit to the legend) [[File:ranges.PNG|600px]] 6be878d888c0b906a514a5fc5d535fb334133fd1 2573 2571 2017-11-28T10:33:36Z Fli091 93 Added [[Category:Mikroelektronikk]] to this page so is listed wikitext text/x-wiki == Introduction and overview == This is a simple tutorial for GATE (Geant4) installation and usage, originally presented as a workshop for the pCT group in March 2017. # [http://geant4.in2p3.fr/spip.php?rubrique8 Geant4 and ROOT virtual machine] # [http://wiki.opengatecollaboration.org/index.php/Compilation_Instructions_V8.0 Gate installation] Agenda for the day is as follows: # An introduction to GATE macros, i.e. GATE input scripts # Setting up a simple simulation geometry in GATE using a proton bencil beam and a water phantom # Running short simulations # Examination of the GATE-output files == GATE == ''Simulations of Preclinical and Clinical Scans in Emission Tomography, Transmission Tomography and Radiation Therapy'' Geant4 is a C++ library, where an application / simulation is built by writing certain C++ classes (geometry, beam, scoring, output, physics), and compiling the binaries from where the simulations are run. Only certain modifications to the simulations can be made with the binaries, such as beam settings, certain physics settings as well as geometry objects pre-defined to be variable. GATE is an application written for Geant4. It was originally meant for PET and SPECT uses, however it is very flexible so many different kinds of detectors can be designed. To run GATE, only macro files written in the Geant4 scripting language (with some GATE specific commands) are needed to build the geometry, scoring, physics and beam. The output is also defined in the macro files, either to ASCII files or to ROOT files. In each simulation, the user has to: # define the scanner geometry # set up the physics processes # initialize the simulation # set up the detector model # define the source(s) # specify the data output format # start the acquisition === Introduction to GATE macros === Gate, just as GEANT4, is a program in which the user interface is based on scripts. To perform actions, the user must either enter commands in interactive mode, or build up macro files containing an ordered collection of commands. Each command performs a particular function, and may require one or more parameters. The Gate commands are organized following a tree structure, with respect to the function they represent. For example, all geometry-control commands start with geometry, and they will all be found under the ''/geometry/'' branch of the tree structure. When Gate is run, the '''Idle>''' prompt appears. At this stage the command interpreter is active; i.e. all the Gate commands entered will be interpreted and processed on-line. All functions in Gate can be accessed to using command lines. The geometry of the system, the description of the radioactive source(s), the physical interactions considered, etc., can be parameterized using command lines, which are translated to the Gate kernel by the command interpreter. In this way, the simulation is defined one step at a time, and the actual construction of the geometry and definition of the simulation can be seen on-line. If the effect is not as expected, the user can decide to re-adjust the desired parameter by re-entering the appropriate command on-line. Although entering commands step by step can be useful when the user is experimenting with the software or when he/she is not sure how to construct the geometry, there remains a need for storing the set of commands that led to a successful simulation. Macros are ASCII files (with '.mac' extension) in which each line contains a command or a comment. Commands are GEANT4 or Gate scripted commands; comments start with the character ' #'. Macros can be executed from within the command interpreter in Gate, or by passing it as a command-line parameter to Gate, or by calling it from another macro. A macro or set of macros must include all commands describing the different components of a simulation in the right order. Usually these components are visualization, definitions of volumes (geometry), systems, digitizer, physics, initialization, source, output and start. These steps are described in the next sections. A single simulation may be split into several macros, for instance one for the geometry, one for the physics, etc. Usually, there is a master macro which calls the more specific macros. Splitting macros allows the user to re-use one or more of these macros in several other simulations, and/or to organize the set of all commands. To execute a macro (mymacro.mac in this example) from the Linux prompt, just type : Gate mymacro.mac To execute a macro from inside the Gate environment, type after the "Idle>" prompt: Idle>/control/execute mymacro.mac And finally, to execute a macro from inside another macro, simply write in the master macro: /control/execute mymacro.mac === Setting up a simple simulation geometry in GATE using a pencil beam and a water phantom === ==== Visualization ==== First we may want to set up a visualization engine to see what's going on. This is optional, and runs in batch mode should not be visualized! Here we use the opengl visualizer OGLX, but different kinds of visualization engines are discussed in the [http://wiki.opengatecollaboration.org/index.php/Users_Guide_V7.2:Visualization GATE wiki] /vis/open OGLSX /vis/viewer/reset /vis/viewer/set/viewpointThetaPhi 60 60 /vis/viewer/zoom 1 /vis/viewer/set/style surface /vis/drawVolume /tracking/storeTrajectory 1 /vis/scene/endOfEventAction accumulate /vis/viewer/update Most of these commands are self explainatory. By using the storeTrajectory command, all particles are displayed together with the geometry. ==== Materials database ==== The default material assigned to a new volume is Air. The list of available materials is defined in the GateMaterials.db file. It's included in the Gate folder, and should be copied to the active directory. It is easy to add new materials to the file, just have a look at the file. /gate/geometry/setMaterialDatabase MyMaterialDatabase.db ==== Geometry ==== Apart from specialized geometries such as PET, SPECT, CT, the general geometry is called as ''scanner''. It must be placed within the ''world'' volume, and all parts of the detector (to be scored) be placed within the ''scanner'' volume. [[File:geometry_hiarerachy.png|400px]] To construct a simple water phantom geometry of 30x30x30 cm, use the following commands: /gate/world/geometry/setXLength 1000. cm /gate/world/geometry/setYLength 1000. cm /gate/world/geometry/setZLength 1000. cm So we've defined a world geometry of 1 m³. It must be larger than all its daughter volumes. Let's put the ''scanner'' volume inside the ''world'' volume. Since it's not already defined (the ''world'' volume was), we must insert a ''box'' object (with parameters XLength, YLength, ZLength as the side measurements of the box): /gate/world/daughters/name scanner /gate/world/daughters/insert box /gate/scanner/geometry/setXLength 100. cm /gate/scanner/geometry/setYLength 100. cm /gate/scanner/geometry/setZLength 100. cm /gate/scanner/placement/setTranslation 0 0 50. cm /gate/scanner/vis/forceWireframe Inside this scanner volume (the default material is Air): /gate/scanner/daughters/name phantom /gate/scanner/daughters/insert box /gate/phantom/geometry/setXLength 30. cm /gate/phantom/geometry/setYLength 30. cm /gate/phantom/geometry/setZLength 30. cm /gate/phantom/placement/setTranslation 0 0 -15. cm /gate/phantom/setMaterial Water /gate/phantom/vis/forceWireframe It is possible to repeat volumes. The simple method is to use a linear replicator: /gate/phantom/repeaters/insert linear /gate/phantom/linear/autoCenter false /gate/phantom/linear/setRepeatNumber 10 /gate/phantom/linear/setRepeatVector 0 0 35. cm The autoCenter command: The original volume is anchored (false), instead of the center-of-mass of all copies being centered at that position (true). ==== Sensitive Detectors ==== The scoring system in Geant4/GATE is based around ''Sensitive Detectors'' (SD). If a volume is a daughter volume (or grand-daughter, ...), it may be assigned as a SD. This process is super simple in GATE: /gate/phantom/attachCrystalSD If you want to define hierarchically repeated structures, such as layers or individually simulated pixels, they should be defined as a ''level'': /gate/scanner/level1/attach phantom /gate/scanner/level2/attach repeatedStructureWithinPhantom And now you can use the ROOT leaf ''level1ID'' and ''level2ID'' to identify the volume. ==== Physics ==== There are many physics lists to choose from in Geant4/GATE. For proton therapy and detector simulations, I most often use a combination of a low-energy-friendly hadronic list and the variable-steplength (for Bragg Peak accuracy) electromagnetic list. From the [http://geant4.cern.ch/support/physicsLists/referencePL/referencePL.shtml Geant4 reference physics webpage]: * QGSP: QGSP is the basic physics list applying the quark gluon string model for high energy interactions of protons, neutrons, pions, and Kaons and nuclei. The high energy interaction creates an exited nucleus, which is passed to the precompound model modeling the nuclear de-excitation. * QGSP_BIC: Like QGSP, but using Geant4 Binary cascade for primary protons and neutrons with energies below ~10GeV, thus replacing the use of the LEP model for protons and neutrons In comparison to the LEP model, Binary cascade better describes production of secondary particles produced in interactions of protons and neutrons with nuclei. * emstandard_opt3 designed for any applications required higher accuracy of electrons, hadrons and ion tracking without magnetic field. It is used in extended electromagnetic examples and in the QGSP_BIC_EMY reference Physics List. An overview over the different electromagnetic physics lists can be found [http://geant4.cern.ch/collaboration/working_groups/electromagnetic/physlist10.3.shtml here]. The physics list to use all of these is called ''QGSP_BIC_EMY''. It is loaded with the command /gate/physics/addPhysicsList QGSP_BIC_EMY In addition, in order to accurately represent the water in the water phantom, we define the current recommended value for the mean ionization potential for water, which is <math>75\ \mathrm{eV}</math>. This can be performed for all materials, and it will override Bragg's additivity rule. /gate/geometry/setIonisationPotential Water 75 eV ==== Initialization ==== After the geometry and physics has been set, initialize the run! /gate/run/initialize ==== Proton beam ==== /gate/source/addSource PBS PencilBeam /gate/source/PBS/setParticleType proton /gate/source/PBS/setEnergy 188.0 MeV /gate/source/PBS/setSigmaEnergy 1.0 MeV /gate/source/PBS/setPosition 0 0 -10. mm /gate/source/PBS/setSigmaX 2 mm /gate/source/PBS/setSigmaY 4 mm /gate/source/PBS/setSigmaTheta 3.3 mrad /gate/source/PBS/setSigmaPhi 3.8 mrad /gate/source/PBS/setEllipseXThetaEmittance 15 mm*mrad /gate/source/PBS/setEllipseXThetaRotationNorm negative /gate/source/PBS/setEllipseYPhiEmittance 20 mm*mrad /gate/source/PBS/setEllipseYPhiRotationNorm negative /gate/application/setTotalNumberOfPrimaries 5000 It is tricky to use this beam since all parameters need to match, so an '''alternative''' is to use a uniform General Particle Source: /gate/source/addSource uniformBeam gps /gate/source/uniformBeam/gps/particle proton /gate/source/uniformBeam/gps/ene/type Gauss /gate/source/uniformBeam/gps/ene/mono 188 MeV /gate/source/uniformBeam/gps/ene/sigma 1 MeV /gate/source/uniformBeam/gps/type Plane /gate/source/uniformBeam/gps/shape Square /gate/source/uniformBeam/gps/direction 0 0 1 /gate/source/uniformBeam/gps/halfx 0 mm /gate/source/uniformBeam/gps/halfy 0 mm /gate/source/uniformBeam/gps/centre 0 0 -1 cm /gate/application/setTotalNumberOfPrimaries 5000 ==== Output ==== For this tutorial, we will use the ROOT output. /gate/output/root/enable /gate/output/root/setFileName gate_simulation ==== Running the simulation ==== To finalize the macro file, start the randomization engine and run! /gate/random/setEngineName MersenneTwister /gate/random/setEngineSeed auto /gate/application/start === Running short simulations === To run a simulation, create a macro file with the lines as descibed above, and run it with $ Gate waterphantom.mac The terminal output describes the geometry, physics, etc. If you want the visualization to be persistent, use instead $ Gate ... [TEXT] Idle> /control/execute waterphantom.mac It is also possible to use aliases in the macro file. For example, to simplify the energy selection, substitute with the line /gate/source/PBS/setEnergy {energy} MeV and run the macro with $ Gate -a '[energy,175]' waterphantom.mac Multiple aliases can be stacked: $ Gate -a '[energy,175] [phantomsize,45]' waterphantom.mac if you have defined multiple alises in the macro file. It is sadly not possible to do calculations in the macro language, so you have to do that through bash (<code>newvalue=`echo "$oldvalue/2" | bc`</code>). === Examination of the GATE output files === The ROOT output file(s) from the simulation can be opened several ways: * By using the built-in <code>TBrowser</code> to look at scoring variable distributions * By using loading the ROOT Tree into a C++ program and looping over events (interactions) ==== Using the built-in <code>TBrowser</code> ==== The hierarchy for the files are shown in the image below: [[File:root_file_hierarchy.PNG|600px]] In Gate, the TTree is called ''Hits'', and the leaves are named after the different variables that are automatically scored: PDGEncoding - The Particle ID trackID - Track number following a mother particle parentID - The parent track's event ID. 0 if the current particle is a beam particle time - Time in simulation (for ToF in PET, etc.) edep - Deposited energy in this event / interaction stepLength - The length of the current step posX - Global X position of event posY - Global Y position of event posZ - Global Z position of event localPosX - Local (in mother volume) X position of event localPosY - Local (in mother volume) Y position of event localPosZ - Local (in mother volume) Z position of event baseID - ID of mother volume ''scanner'', == 0 if only one ''scanner'' defined level1ID - ID of 1st level of volume hierarchy level2ID - ID of 2nd level of volume hierarchy level3ID - ID of 3rd level of volume hierarchy level4ID - ID of 4th level of volume hierarchy sourcePosX - Global X position of source particle sourcePosY - Global Y position of source particle sourcePosZ - Global X position of source particle eventID - History number (important!!) volumeID - ID of current volume (useful to isolate particles in a specific part of a fully scored volume) processName - A string containing the name of the interaction type: - hIoni: Ionization by hadron - Transportation: No special interactions (usually from step limiter) - eIoni: Ionization by electron - ProtonInelastic: Inelastic nuclear interaction of proton - compt: Compton scattering - ionIoni: Ionization by ion - msc: Multiple Coulomb Scattering process - hadElastic: Elastic hadron / proton scattering An example of the distribution of eventID (in histogram form, this is the number of interactions per particle (if bin size = 1)) $ root ROOT [0] new TBrowser [[File:root.PNG|600px]] Or for the Z distribution (see the Bragg Peak) [[File:root2.PNG|600px]] ==== Opening the files in C++ ==== It is quite simple to open the generated ROOT files in a C++ program. In <code>openROOTFile.C</code>: #include <TTree.h> #include <TFile.h> using namespace std; void Run() { TFile *f = new TFile("gate_simulation.root"); TTree *tree = (TTree*) f->Get("Hits"); // The TTree in the GATE file is called ''Hits'' // Declare the variables (leafs) to be readout Float_t x,y,z,edep; Int_t eventID, parentID; // Make a connection between the declared variables and the leafs tree->SetBranchAddress("posX", &x); tree->SetBranchAddress("posY", &y); tree->SetBranchAddress("posZ", &z); tree->SetBranchAddress("edep", &edep); tree->SetBranchAddress("eventID", &eventID); tree->SetBranchAddress("parentID", &parentID); // Loop over all the entries in the tree for (Int_t i=0, i < tree->GetEntries(); ++i) { tree->GetEntry(i); if (eventID > 2) break; // To limit the output! if (parentID != 0) continue; // Only show results from primary particles printf("Primary particle with event ID %d has an interaction with %.2f MeV energy loss at (x,y,z) = (%.2f, %.2f, %.2f).\n", eventID, edep, x, y, z); } delete f; } Then you can run the program with $ root ROOT [0] .L openROOTFile.C+ // The + tells ROOT to compile the code ROOT [1] Run(); Please note that it is also possible to make a complete class to read out the root files using ROOT's <code>MakeClass</code> function. See [http://wiki.opengatecollaboration.org/index.php/Users_Guide_V7.2:Data_output#How_to_analyze_the_Root_output "How to analyze the ROOT output"]. ==== Test case: Finding the range and straggling of a proton beam ==== #include <TTree.h> #include <TH1F.h> #include <TFile.h> #include <TF1.h> using namespace std; void Run() { TFile * f = new TFile("gate_simulation.root"); TTree * tree = (TTree*) f->Get("Hits"); // The TTree in the GATE file is called ''Hits'' TH1F * rangeHistogram = new TH1F("rangeHistogram", "Stopping position for protons"; 800, 0, 400); // Histogram 1D with Float values Float_t z; Int_t eventID, parentID; Int_t lastEventID = -1; Float_t lastZ = -1; tree->SetBranchAddress("posZ", &z); tree->SetBranchAddress("eventID", &eventID); tree->SetBranchAddress("parentID", &parentID); for (Int_t i=0, i < tree->GetEntries(); ++i) { tree->GetEntry(i); if (parentID != 0) continue; // Check if this is the first event of a primary particle if (eventID != lastEventID && lastEventID >= 0) { rangeHistogram->Fill(lastZ); } // Store the current variables lastZ = z; lastEventID = eventID; } rangeHistogram->Draw(); // Make a Gaussian fit to the range TF1 * fit = new TF1("fit", "gaus"); rangeHistogram->Fit("fit", "", "", 150, 250); // Most probable values for fit is in this range, ROOT is quite sensitive to Gaussians occupying only a small part of the histogram, so give narrow fit range printf("The range of the proton beam is %.3f +- %.3f mm.\n", fit->GetParameter(1), fit->GetParameter(2)); } This time, the program will yield the following output (from a 250 MeV beam): The range of the proton beam is 378.225 mm +- 3.791 mm With the following histogram (I've added some color and a SetOptFit to the legend) [[File:ranges.PNG|600px]] [[Category:Mikroelektronikk]] 15b0dea896673f5af35d44ae70fcbed7e58c20a3 2 608 2572 2508 2017-11-28T10:32:21Z Fli091 93 wikitext text/x-wiki [mailto:fli091@uib.no mailto:fli091@uib.no] == Diverse lenker == * [https://www.eda.ncsu.edu/wiki/FreePDK The FreePDKTM process design kit is an open-source, Open-Access-based PDK for the 45nm technology] * [http://venividiwiki.ee.virginia.edu/mediawiki/index.php/ToolsCadenceTutorialsBasicSimulationOceanFreePDK Simulere med Cadence via OCEAN skript] * [https://drive.google.com/file/d/0B8aUrqN1GG-DMl9Mc29rQnRpaVE/edit En presentasjon av hvordan lage OCEANskript] b196b4f4761be841d186a35746877c1eaa502161 2 629 2574 2017-11-28T13:15:05Z Yag005 96 Created page with "Master student in microelectronics group. Contact email: yag005@student.uib.no" wikitext text/x-wiki Master student in microelectronics group. Contact email: yag005@student.uib.no 7a8aa39b24ce34569d5fc3e41f503babc1515392 0 25 2575 2394 2017-11-28T13:17:39Z Yag005 96 /* Annet */ wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[FreeRTOS]] Free Real Time Operating System == Andre fagressurser og laboratorieveiledninger== * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] b26fc3069fbc3351b99224da58db1a3f681ae22f 0 630 2576 2017-11-28T13:19:34Z Yag005 96 Created page with "[[FSBL]] First Stage Bootloader" wikitext text/x-wiki [[FSBL]] First Stage Bootloader 8c1ebba3b6832641c05ed1ab7a2630f60d1667ee 2577 2576 2017-11-28T13:21:20Z Yag005 96 wikitext text/x-wiki [[FreeRTOS FSBL]] First Stage Bootloader b658e7bc67f2798bcf6f244a2459322c962208ac 2578 2577 2017-11-28T13:23:01Z Yag005 96 wikitext text/x-wiki [[FreeRTOS FSBL]] - First Stage Bootloader: Run FreeRTOS by booting OS and application project from SD-card 4c2d49071621b7cd8258fbadf821b20e083fe47b 0 631 2579 2017-11-28T13:33:45Z Yag005 96 Created page with "Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-t..." wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. ===== Exporting hardware bitstream ===== cc06828c6265dcc0f41425c1fee3d9c954b78a71 2580 2579 2017-11-28T13:42:01Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. ===== Exporting hardware bitstream ===== After the bitstream was generated in the previous tutorial, it is now possible to export it. ''Goto: File -> Export -> Export Hardware..'' Click to include bitstream, and press "OK". Next, goto: ''File -> Launch SDK''. The following window will appear: [[File:Launch SDK.png|thumbnail]] Press "OK". 742c884c756c012f60e8219e19a20134b5000df1 2582 2580 2017-11-28T13:44:20Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. ===== Exporting hardware bitstream ===== After the bitstream was generated in the previous tutorial, it is now possible to export it. ''Goto: File -> Export -> Export Hardware..'' Click to include bitstream, and press "OK". Next, goto: ''File -> Launch SDK''. The following window will appear: [[File:Launch SDK.png|thumbnail|center]] Press "OK". 5eb37c1405a09d118b3af2f94d1d9713f3059d29 2584 2582 2017-11-28T13:46:30Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. ===== Exporting hardware bitstream ===== After the bitstream was generated in the previous tutorial, it is now possible to export it. ''Goto: File -> Export -> Export Hardware..'' Make sure to include bitstream, and press "OK". [[File:export_hardware.png|400px|center]] Next, goto: ''File -> Launch SDK''. The following window will appear: [[File:Launch SDK.png|thumbnail|center]] Press "OK". 5ec66e8b5a97750e8926cb4bad8f02a5a150ecd0 2585 2584 2017-11-28T13:46:46Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. ===== Exporting hardware bitstream ===== After the bitstream was generated in the previous tutorial, it is now possible to export it. ''Goto: File -> Export -> Export Hardware..'' Make sure to include bitstream, and press "OK". [[File:export_hardware.png|thumbnail|center]] Next, goto: ''File -> Launch SDK''. The following window will appear: [[File:Launch SDK.png|thumbnail|center]] Press "OK". 474273cdda8be2f23d2d50fdb324eae02a97669c 2586 2585 2017-11-28T13:50:04Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. ===== Exporting hardware bitstream ===== After the bitstream was generated in the previous tutorial, it is now possible to export it. ''Goto: File -> Export -> Export Hardware..'' Make sure to include bitstream, and press "OK". [[File:export_hardware.png|thumbnail|center]] Next, goto: ''File -> Launch SDK''. The following window will appear: [[File:Launch SDK.png|thumbnail|center]] Press "OK" and wait for Xilinx SDK to start up and finish loading. ... Work in progress ... e66931d76f44f81bfd2a57ced6ed41aaf43b8ed7 6 632 2581 2017-11-28T13:42:51Z Yag005 96 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 633 2583 2017-11-28T13:46:08Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 634 2587 2017-11-28T13:54:29Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2588 2587 2017-11-28T13:57:04Z Yag005 96 Yag005 uploaded a new version of [[File:New project name.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2590 2588 2017-11-28T14:00:03Z Yag005 96 Yag005 uploaded a new version of [[File:New project name.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2592 2590 2017-11-28T14:01:49Z Yag005 96 Yag005 uploaded a new version of [[File:New project name.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 635 2589 2017-11-28T13:57:24Z Yag005 96 Created page with "Tested on Xilinx Vivado 2017.3. Start Vivado Goto: ''File -> New Project -> Next''. For this project we will name it axi4_lite_tutorial_project. File:new_project_name.png|..." wikitext text/x-wiki Tested on Xilinx Vivado 2017.3. Start Vivado Goto: ''File -> New Project -> Next''. For this project we will name it axi4_lite_tutorial_project. [[File:new_project_name.png|thumbnail|center]] 99c5e96dff99bf190ed4a638907deadfa84a8008 2591 2589 2017-11-28T14:00:31Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3. Start Vivado Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials.[[:File:new_project_name.png|thumbnail|center]] 2305b135f19ba78e16ace2ebfc7f87e8c64cc6fc 2593 2591 2017-11-28T14:02:04Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3. Start Vivado Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. [[File:New_project_name.png|thumbnail|center]] 7f4d1d1f46641d6826ff32c56e40c4a632d1bb63 2594 2593 2017-11-28T14:10:47Z Yag005 96 wikitext text/x-wiki [[File:Example.jpg|thumbnail]]Tested on Xilinx Vivado 2017.3. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both Target and Simulator Language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. c71cf0fabbe613d3df7c5159af00f43293502820 2596 2594 2017-11-28T14:28:22Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. 9a50bf85855b876f4861c0391fdef7ae5cc14da2 2599 2596 2017-11-28T14:36:55Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created, and IP-blocks can be integrated: Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. The window should now look like this: [[File:first_block.png|thumbnail|center]] e915c6909cf0ea49ee1203253b1bf70493891c5b 2600 2599 2017-11-28T14:37:30Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created, and IP-blocks can be integrated: Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. The window should now look like this: [[File:first_block.png|thumbnail|left]] 8085a66ac393c760fadb6276b52148ca313a93cf 2601 2600 2017-11-28T14:38:20Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created, and IP-blocks can be integrated: Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. The window should now look like this: [[File:first_block.png|thumbnail|left]] a2e97e69675caec4317fbedcf21d8ceee3ddb633 2602 2601 2017-11-28T14:38:55Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created, and IP-blocks can be integrated: Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|left]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. The window should now look like this: [[File:first_block.png|thumbnail|left]] c2ea27f72312a97544fb389bac86303d45151441 2604 2602 2017-11-28T14:43:18Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|left]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|left]] 0b5581dafc676f9a961d8afee006b14f570249b1 2605 2604 2017-11-28T14:43:37Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|left]] 2a9151cf1b7285c3cae612d6ada7420a6c76201a 2606 2605 2017-11-28T15:02:35Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|left]] Goto: ''Tools -> Create and Package New IP''. Choose Create a New AXI3 peripheral, and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. 12b6fc0e1312f140216201c04362f22380742047 2608 2606 2017-12-04T13:44:30Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|left]] Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0". eaa68680d159856cb3113edee43e0d432ae3b27e 6 636 2595 2017-11-28T14:25:40Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 637 2597 2017-11-28T14:33:34Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 638 2598 2017-11-28T14:36:35Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2603 2598 2017-11-28T14:43:10Z Yag005 96 Yag005 uploaded a new version of [[File:First block.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 639 2607 2017-12-04T13:44:03Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 640 2609 2017-12-04T13:47:14Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2610 2609 2017-12-04T14:24:22Z Yag005 96 Yag005 uploaded a new version of [[File:Diagram axi4lite periph added.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 641 2611 2017-12-04T16:48:04Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2619 2611 2017-12-04T16:52:36Z Yag005 96 Yag005 uploaded a new version of [[File:Led port success.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 642 2612 2017-12-04T16:48:04Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 643 2613 2017-12-04T16:48:05Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 644 2614 2017-12-04T16:48:05Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 645 2615 2017-12-04T16:48:05Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 646 2616 2017-12-04T16:49:12Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 635 2617 2608 2017-12-04T16:49:19Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|center]] Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0" and add it. Run connection/block automation with default parameters. [[File:diagram_axi4lite_periph_added.png|center]]<br /> Right click on "design_1" under "Block Designs" in the Sources design tree. Click "Create HDL Wrapper", and let Vivado manage wrapper and auto-update. ''Right click axi4_lite_led_IP_0 block --> Edit in IP Packager''. [[File:led_ip_1.png|400px]] [[File:led_ip_2.png|400px]] [[File:led_ip_3.png|400px]] [[File:S00_1.png|400px]] [[File:S00_2.png|400px]] [[File:led_port_success.png|400px]] Find the following files under Sources: ''Design Sources --> design_1_wrapper --> design_1_i: design_1 --> design_1 --> axi4_lite_led_IP_0 : design_1_axi4_lite_led_IP_0_1 --> design_1_axi4_lite_led_IP_0_1'', or if you want to do the editing in your favorite editor, find the files in ''axi4_lite_tutorial_project/axi4_lite_tutorial_project.srcs/sources_1/bd/design_1/ipshared/4b4e/hdl''<br /> axi4_lite_led_IP_v1_0_S00_AXI.vhd <br /> axi4_lite_led_IP_v1_0.vhd<br /> <br /> We will start by editing axi4_lite_led_IP_v1_0.vhd using the Visual Studio Code editor:<br /> <br /> Then editing axi4_lite_led_IP_v1_0_S00_AXI.vhd:<br /> Choose "Ports and interfaces" in the Package IP tab. Click "Merge changes from Ports and Interfaces Wizard". A new port should now be listed named "led_port". Click on "Review and Package", and click Re-Package IP. Click yes on prompt to close project. Click on "IP Status" tab, and choose "Upgrade Selected". a97e3da646ec56910b34fddb34a01644b78516e4 2618 2617 2017-12-04T16:52:01Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|center]] Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0" and add it. Run connection/block automation with default parameters. [[File:diagram_axi4lite_periph_added.png|center]]<br /> Right click on "design_1" under "Block Designs" in the Sources design tree. Click "Create HDL Wrapper", and let Vivado manage wrapper and auto-update. ''Right click axi4_lite_led_IP_0 block --> Edit in IP Packager''. Then do the following edits to axi4_lite_led_IP_v1_0_S00_AXI.vhd and axi4_lite_led_IP_v1_0.vhd<br /> <br /> [[File:led_ip_1.png|400px]] [[File:led_ip_2.png|400px]] [[File:led_ip_3.png|400px]] [[File:S00_1.png|400px]] [[File:S00_2.png|400px]] [[File:led_port_success.png|400px]] Save both files, and go into the "Ports and interfaces" tab. Click "Merge changes from Ports and Interfaces Wizard". A new port should now be listed named "led_port". Click on "Review and Package", and click Re-Package IP. Click yes on prompt to close project. Click on "IP Status" tab, and choose "Upgrade Selected" if you are not automatically prompted. e31a9483e7b559d83b2c7b575a4eb8233944eddd 2620 2618 2017-12-04T17:01:45Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|center]] Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0" and add it. Run connection/block automation with default parameters. [[File:diagram_axi4lite_periph_added.png|center]]<br /> Right click on "design_1" under "Block Designs" in the Sources design tree. Click "Create HDL Wrapper", and let Vivado manage wrapper and auto-update. ''Right click axi4_lite_led_IP_0 block --> Edit in IP Packager''. Then do the following edits to axi4_lite_led_IP_v1_0_S00_AXI.vhd and axi4_lite_led_IP_v1_0.vhd<br /> <br /> [[File:led_ip_1.png|400px]] [[File:led_ip_2.png|400px]] [[File:led_ip_3.png|400px]] [[File:S00_1.png|400px]] [[File:S00_2.png|400px]] Save both files, and go into the "Ports and interfaces" tab. Click "Merge changes from Ports and Interfaces Wizard". A new port should now be listed named "led_port". Click on "Review and Package", and click Re-Package IP. Click yes on prompt to close project. Click on "IP Status" tab, and choose "Upgrade Selected" if you are not automatically prompted. Go back to the Block design diagram, and right-click on the newly created port named "led_port[3:0]" on our custom IP and choose "make external". Save. Open the constraints file ZYBO_Master.xdc located under Constraints in the sources tab design tree. To avoid tons of warnings, comment out everything except from the 4 lines under "##LEDs". Rewrite them to the following:<br /><br /> set_property -dict { PACKAGE_PIN M14 IOSTANDARD LVCMOS33 } [get_ports { led_port[3] }]; #IO_L23P_T3_35 Sch=LED0<br /> set_property -dict { PACKAGE_PIN M15 IOSTANDARD LVCMOS33 } [get_ports { led_port[2] }]; #IO_L23N_T3_35 Sch=LED1<br /> set_property -dict { PACKAGE_PIN G14 IOSTANDARD LVCMOS33 } [get_ports { led_port[1] }]; #IO_0_35=Sch=LED2<br /> set_property -dict { PACKAGE_PIN D18 IOSTANDARD LVCMOS33 } [get_ports { led_port[0] }]; #IO_L3N_T0_DQS_AD1N_35 Sch=LED3<br /> 9369b43799b5a3e7e8027037100a15786a90f369 2621 2620 2017-12-04T17:02:26Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|center]] Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0" and add it. Run connection/block automation with default parameters. [[File:diagram_axi4lite_periph_added.png|center]]<br /> Right click on "design_1" under "Block Designs" in the Sources design tree. Click "Create HDL Wrapper", and let Vivado manage wrapper and auto-update. ''Right click axi4_lite_led_IP_0 block --> Edit in IP Packager''. Then do the following edits to axi4_lite_led_IP_v1_0_S00_AXI.vhd and axi4_lite_led_IP_v1_0.vhd<br /> <br /> [[File:led_ip_1.png|400px]] [[File:led_ip_2.png|400px]] [[File:led_ip_3.png|400px]] [[File:S00_1.png|400px]] [[File:S00_2.png|400px]] Save both files, and go into the "Ports and interfaces" tab. Click "Merge changes from Ports and Interfaces Wizard". A new port should now be listed named "led_port". Click on "Review and Package", and click Re-Package IP. Click yes on prompt to close project. Click on "IP Status" tab, and choose "Upgrade Selected" if you are not automatically prompted. Go back to the Block design diagram, and right-click on the newly created port named "led_port[3:0]" on our custom IP and choose "make external". Save. Open the constraints file ZYBO_Master.xdc located under Constraints in the sources tab design tree. To avoid tons of warnings, comment out everything except from the 4 lines under "##LEDs". Rewrite them to the following:<br /><br /> set_property -dict { PACKAGE_PIN M14 IOSTANDARD LVCMOS33 } [get_ports { led_port[3] }]; <br /> set_property -dict { PACKAGE_PIN M15 IOSTANDARD LVCMOS33 } [get_ports { led_port[2] }]; <br /> set_property -dict { PACKAGE_PIN G14 IOSTANDARD LVCMOS33 } [get_ports { led_port[1] }]; <br /> set_property -dict { PACKAGE_PIN D18 IOSTANDARD LVCMOS33 } [get_ports { led_port[0] }]; <br /> 4c1e71c9fc5411f38e07496f6dedfcac51f7238b 2622 2621 2017-12-04T18:11:22Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|center]] Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0" and add it. Run connection/block automation with default parameters. [[File:diagram_axi4lite_periph_added.png|center]]<br /> Right click on "design_1" under "Block Designs" in the Sources design tree. Click "Create HDL Wrapper", and let Vivado manage wrapper and auto-update. ''Right click axi4_lite_led_IP_0 block --> Edit in IP Packager''. Then do the following edits to axi4_lite_led_IP_v1_0_S00_AXI.vhd and axi4_lite_led_IP_v1_0.vhd<br /> <br /> [[File:led_ip_1.png|400px]] [[File:led_ip_2.png|400px]] [[File:led_ip_3.png|400px]] [[File:S00_1.png|400px]] [[File:S00_2.png|400px]] Save both files, and go into the "Ports and interfaces" tab. Click "Merge changes from Ports and Interfaces Wizard". A new port should now be listed named "led_port". Click on "Review and Package", and click Re-Package IP. Click yes on prompt to close project. Click on "IP Status" tab, and choose "Upgrade Selected" if you are not automatically prompted. Go back to the Block design diagram, and right-click on the newly created port named "led_port[3:0]" on our custom IP and choose "make external". Save. Open the constraints file ZYBO_Master.xdc located under Constraints in the sources tab design tree. To avoid tons of warnings, comment out everything except from the 4 lines under "##LEDs". Rewrite them to the following:<br /><br /> set_property -dict { PACKAGE_PIN M14 IOSTANDARD LVCMOS33 } [get_ports { led_port[3] }]; <br /> set_property -dict { PACKAGE_PIN M15 IOSTANDARD LVCMOS33 } [get_ports { led_port[2] }]; <br /> set_property -dict { PACKAGE_PIN G14 IOSTANDARD LVCMOS33 } [get_ports { led_port[1] }]; <br /> set_property -dict { PACKAGE_PIN D18 IOSTANDARD LVCMOS33 } [get_ports { led_port[0] }]; <br /> Save the file, and click "Generate Bitstream". Accept the launch of synthesis and implementation. 3cc946e94e134e11688a6eb7a96c5fd020c191b5 2627 2622 2017-12-06T13:23:12Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|center]] Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0" and add it. Run connection/block automation with default parameters. [[File:diagram_axi4lite_periph_added.png|center]]<br /> Right click on "design_1" under "Block Designs" in the Sources design tree. Click "Create HDL Wrapper", and let Vivado manage wrapper and auto-update. ''Right click axi4_lite_led_IP_0 block --> Edit in IP Packager''. Then do the following edits to axi4_lite_led_IP_v1_0_S00_AXI.vhd and axi4_lite_led_IP_v1_0.vhd<br /> <br /> [[File:led_ip_1.png|400px]] [[File:led_ip_2.png|400px]] [[File:led_ip_3.png|400px]] [[File:S00_1.png|400px]] [[File:S00_2.png|400px]] Save both files, and go into the "Ports and interfaces" tab. Click "Merge changes from Ports and Interfaces Wizard". A new port should now be listed named "led_port". Click on "Review and Package", and click Re-Package IP. Click yes on prompt to close project. Click on "IP Status" tab, and choose "Upgrade Selected" if you are not automatically prompted. Go back to the Block design diagram, and right-click on the newly created port named "led_port[3:0]" on our custom IP and choose "make external". Save. Open the constraints file ZYBO_Master.xdc located under Constraints in the sources tab design tree. To avoid tons of warnings, comment out everything except from the 4 lines under "##LEDs". Rewrite them to the following:<br /><br /> set_property -dict { PACKAGE_PIN M14 IOSTANDARD LVCMOS33 } [get_ports { led_port[3] }]; <br /> set_property -dict { PACKAGE_PIN M15 IOSTANDARD LVCMOS33 } [get_ports { led_port[2] }]; <br /> set_property -dict { PACKAGE_PIN G14 IOSTANDARD LVCMOS33 } [get_ports { led_port[1] }]; <br /> set_property -dict { PACKAGE_PIN D18 IOSTANDARD LVCMOS33 } [get_ports { led_port[0] }]; <br /> Save the file, and click "Generate Bitstream". Accept the launch of synthesis and implementation. When complete, you can choose to open the implemented design and have a look at it, or specify timing restraints. = Exporting Bitstream = Goto: ''File --> Export --> Export Hardware'', and choose to include bitstream. You are now done with this tutorial. 61118ae5d25ca89d7e9452694b1f46027e1d097e 2628 2627 2017-12-06T13:25:42Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado 2017.3, using the Xilinx Digilent Zybo SoC. = Create a Project = Start ./vivado from installed directory. Goto: ''File -> New Project -> Next''. For this project we will name it "axi4_lite_tutorial_project" and place it in a folder named tutorials. Click Next and choose RTL Project, then Next. [[File:New_project_name.png|thumbnail|center]] Do not add any sources, but make sure that both target and simulator language is set to the appropriate language you're using. In this project we will use VHDL. Click Next. Here you must provide a constraints file named "ZYBO_Master.xdc", available from [https://github.com/Digilent/digilent-xdc/ GitHub]. Make sure that the option to copy the constraints file(s) into the project is marked. For the next step, the board files for the board we're using must have been installed. If this is not the case, follow [https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 this tutorial] to do so. [[File:new_project_default_part.png|thumbnail|center]] Choose the Zybo board, click next, and finish. = Creating a block desgin = The project has now been created and ready for IP-block integration. Click on "Create Block Design" in the left of the window. Give the design a name, for instance design_1, and click "OK".[[File:create_block_design.png|thumbnail|center]] Now press the "+" button in the diagram window, and search for "ZYNQ7 Processing System". Double click to add. In the top of the window an option to "Run Block Automation" appears.. Click this, and complete with default settings. The window should now look like this: [[File:first_block.png|thumbnail|center]] = Create a Custom AXI4-lite IP block = Goto: ''Tools -> Create and Package New IP''. Choose "Create a New AXI4 peripheral", and click next. Name the IP "axi4_lite_led_IP" or any other suiting name. You can leave all other parameters default. In the next window, ensure the IP contains one slave interface named S00_AXI of type "Lite". Click next, and choose "Add IP to the repository". Finish.[[File:add_interfaces_axi4lite.png|thumbnail|center]] In the diagram window it's now possible to add the IP we just created, using the "+" button. Search for "axi4_lite_led_IP_v1.0" and add it. Run connection/block automation with default parameters. [[File:diagram_axi4lite_periph_added.png|center]]<br /> Right click on "design_1" under "Block Designs" in the Sources design tree. Click "Create HDL Wrapper", and let Vivado manage wrapper and auto-update. ''Right click axi4_lite_led_IP_0 block --> Edit in IP Packager''. Then do the following edits to axi4_lite_led_IP_v1_0_S00_AXI.vhd and axi4_lite_led_IP_v1_0.vhd<br /> <br /> [[File:led_ip_1.png|400px]] [[File:led_ip_2.png|400px]] [[File:led_ip_3.png|400px]] [[File:S00_1.png|400px]] [[File:S00_2.png|400px]] Save both files, and go into the "Ports and interfaces" tab. Click "Merge changes from Ports and Interfaces Wizard". A new port should now be listed named "led_port". Click on "Review and Package", and click Re-Package IP. Click yes on prompt to close project. Click on "IP Status" tab, and choose "Upgrade Selected" if you are not automatically prompted. Go back to the Block design diagram, and right-click on the newly created port named "led_port[3:0]" on our custom IP and choose "make external". Save. = Editing the Constraints file = Open the constraints file ZYBO_Master.xdc located under Constraints in the sources tab design tree. To avoid tons of warnings, comment out everything except from the 4 lines under "##LEDs" since we're only using them for this project. Rewrite them to the following:<br /><br /> set_property -dict { PACKAGE_PIN M14 IOSTANDARD LVCMOS33 } [get_ports { led_port[3] }]; <br /> set_property -dict { PACKAGE_PIN M15 IOSTANDARD LVCMOS33 } [get_ports { led_port[2] }]; <br /> set_property -dict { PACKAGE_PIN G14 IOSTANDARD LVCMOS33 } [get_ports { led_port[1] }]; <br /> set_property -dict { PACKAGE_PIN D18 IOSTANDARD LVCMOS33 } [get_ports { led_port[0] }]; <br /> Save the file, and click "Generate Bitstream". Accept the launch of synthesis and implementation. When complete, you can choose to open the implemented design and have a look at it, or specify timing restraints. = Exporting Bitstream = Goto: ''File --> Export --> Export Hardware'', and choose to include bitstream. You are now done with this tutorial. 3839cf1c998744f4744492e19677cda055b5273b 0 630 2623 2578 2017-12-06T12:23:12Z Yag005 96 wikitext text/x-wiki [[Running FreeRTOS on Xilinx Zybo]] - How to get FreeRTOS to run on the Xilinx Zybo SoC. [[FreeRTOS FSBL]] - First Stage Bootloader: Run FreeRTOS by booting OS and application project from SD-card. 4818e0b571cca796479959aba640860fa54b0fb4 2624 2623 2017-12-06T12:23:26Z Yag005 96 wikitext text/x-wiki [[Running FreeRTOS on Xilinx Zybo]] - How to get FreeRTOS to run on the Xilinx Zybo SoC.<br /> [[FreeRTOS FSBL]] - First Stage Bootloader: Run FreeRTOS by booting OS and application project from SD-card. aa9451860c97088b9a9dbb3d77a40f950eb5fd38 0 631 2625 2586 2017-12-06T12:25:05Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Running FreeRTOS on Xilinx Zybo]]"-tutorial. ===== Exporting hardware bitstream ===== After the bitstream was generated in the previous tutorial, it is now possible to export it. ''Goto: File -> Export -> Export Hardware..'' Make sure to include bitstream, and press "OK". [[File:export_hardware.png|thumbnail|center]] Next, goto: ''File -> Launch SDK''. The following window will appear: [[File:Launch SDK.png|thumbnail|center]] Press "OK" and wait for Xilinx SDK to start up and finish loading. ... Work in progress ... b6e176bae5c20f2c717714831b37ac51b5645fa9 2656 2625 2017-12-06T17:53:43Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Running FreeRTOS on Xilinx Zybo]]"-tutorial. ===== Creating FSBL ===== The result from the previous tutorial linked at the top of this tutorial, should be a Project Explorer looking like this: [[File:project_explorer_start.png|400px|center]]<br /> Goto ''File --> New --> Application Project''. Name the new project "FSBL" and let OS platform be "standalone". On the next page, choose the "Zynq FSBL"-template. Finish. The Project Explorer should now contain the following: [[File:fsbl_created.png|400px|center]]<br /> d2af558400cfc375401ee2700c8fa179d4036cbb 2657 2656 2017-12-06T18:22:13Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Running FreeRTOS on Xilinx Zybo]]"-tutorial. ===== Creating FSBL ===== The result from the previous tutorial linked at the top of this tutorial, should be a Project Explorer looking like this: [[File:project_explorer_start.png|400px|center]]<br /> Goto ''File --> New --> Application Project''. Name the new project "FSBL" and let OS platform be "standalone". On the next page, choose the "Zynq FSBL"-template. Finish. The Project Explorer should now contain the following: [[File:fsbl_created.png|400px|center]]<br /> Goto ''Xilinx --> Create Boot Image''. Choose the Zynq architecture and click to browse for a Output BIF file path. Name the file "output.bif" and create a folder called "output" within the axi4_lite_tutorial_project.sdk directory. Click OK. Check that the output format is "BIN". Now click add in the Boot Image Partitions section: Choose "Bootloader" as partition type, and navigate to the file "FSBL.elf" under \axi4_lite_tutorial_project.sdk\FSBL\Debug\ in the file path.<br /> Now add a new partition, this time as type "datafile". The file that should be added to file path is "design_1_wrapper.bit" under \axi4_lite_tutorial_project.runs\impl_1\<br /> The third and final partition: Partition type "datafile", name: FreeRTOS_example_project.elf File path: \axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\Debug\<br /> <br /> When all partitions have been added, click "Create Image". Navigate to the directory you specified for output, in our case \axi4_lite_tutorial_project.sdk\output. It should now contain two files: BOOT.bin, and output.bif. Copy the BOOT.bin file onto an SD-card formatted as FAT. Bring up your favorite Xilinx Zybo SoC board, and configure jumper 5 (JP5) for SD boot configuration. Insert the SD card, and connect a power source (wall or USB). Then power up the board. After a couple of seconds, it should behave just as it did when booting from JTAG in the "[[Running FreeRTOS on Xilinx Zybo]]"-tutorial. 60b32b4e50a2cfd13bcb645d9e651d4a5a7527b2 2658 2657 2017-12-06T18:23:32Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Running FreeRTOS on Xilinx Zybo]]"-tutorial. ===== Creating FSBL ===== The result from the previous tutorial linked at the top of this tutorial, should be a Project Explorer looking like this: [[File:project_explorer_start.png|400px|center]]<br /> Goto ''File --> New --> Application Project''. Name the new project "FSBL" and let OS platform be "standalone". On the next page, choose the "Zynq FSBL"-template. Finish. The Project Explorer should now contain the following: [[File:fsbl_created.png|400px|center]]<br /> Goto ''Xilinx --> Create Boot Image''. Choose the Zynq architecture and click to browse for a Output BIF file path. Name the file "output.bif" and create a folder called "output" within the axi4_lite_tutorial_project.sdk directory. Click OK. Check that the output format is "BIN". Now click add in the Boot Image Partitions section: Choose "Bootloader" as partition type, and navigate to the file "FSBL.elf" under \axi4_lite_tutorial_project.sdk\FSBL\Debug\ in the file path.<br /> Now add a new partition, this time as type "datafile". The file that should be added to file path is "design_1_wrapper.bit" under \axi4_lite_tutorial_project.runs\impl_1\<br /> The third and final partition is of type "datafile", has the name "FreeRTOS_example_project.elf", and is found at \axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\Debug\<br /> <br /> When all partitions have been added, click "Create Image". Navigate to the directory you specified for output, in our case \axi4_lite_tutorial_project.sdk\output. It should now contain two files: BOOT.bin, and output.bif. Copy the BOOT.bin file onto an SD-card formatted as FAT. Bring up your favorite Xilinx Zybo SoC board, and configure jumper 5 (JP5) for SD boot configuration. Insert the SD card, and connect a power source (wall or USB). Then power up the board. After a couple of seconds, it should behave just as it did when booting from JTAG in the "[[Running FreeRTOS on Xilinx Zybo]]"-tutorial. b6fd866d111c5e76ba0223b62bb7e2a24afd9410 0 647 2626 2017-12-06T12:25:12Z Yag005 96 Created page with "Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-..." wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. f5d91b1b58ba70b2f2ca983eca838b80224fb006 2629 2626 2017-12-06T13:26:34Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new blank application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". 2e9a7d8826107dec1e10a3b2691aa0a2714ef65c 2632 2629 2017-12-06T14:58:50Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. Download and extract FreeRTOS available at the FreeRTOS homepage: https://www.freertos.org/a00104.html Copy the following files from the downloaded Free into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\ FreeRTOS_asm_vectors.S FreeRTOSConfig.h FreeRTOS_tick_config.c main.c printf-stdarg.c \FreeRTOSV8.2.1\FreeRTOS\Source\ croutine.c event_groups.c list.c queue.c tasks.c timers.c \FreeRTOSV8.2.1\FreeRTOS\Source\include\ croutine.h deprecated_definitions.h event_groups.h FreeRTOS.h list.h mpu_prototypes.h mpu_wrappers.h portable.h projdefs.h queue.h semphr.h StackMacros.h task.h timers.h \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\ heap_4.c \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\ port.c portASM.S portmacro.h 1aaff64e1c36fd120ab3a9289d48421f5dc5881b 2633 2632 2017-12-06T15:03:51Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. Download and extract FreeRTOS available at the FreeRTOS homepage: #REDIRECT [[https://www.freertos.org/a00104.html]]<br /> Copy the following files from the downloaded Free into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> 9d03409c2509d6fc235c3fece57fbf4d7883d576 2634 2633 2017-12-06T15:11:10Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. Download and extract FreeRTOS available at the FreeRTOS homepage: #Link [[https://www.freertos.org/a00104.html]]<br /> Copy the following files from the downloaded Free into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> 1cbf0097596c31383109473d7e4c8c20cc4439bc 2635 2634 2017-12-06T15:16:55Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> Open the extracted into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> 9491fea45bb0f4abdfec68a698a675b3096fcd14 2636 2635 2017-12-06T15:19:48Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> 237fab026cdc8a4d335413b3d90268db97e186a3 2638 2636 2017-12-06T15:23:53Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]] 64f9cd87f130b6fe27c9bbb2a9d08a42f1714a6f 2642 2638 2017-12-06T15:51:50Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder: [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px]|center] 75ddc55b89d8a888600a3a26e2acca2af21540ee 2643 2642 2017-12-06T15:52:54Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder: [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> = Setting CPU frequency = Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px]|center] e4a1c63c24a4daf9938ef35ef9f5ae106207d54d 2644 2643 2017-12-06T15:53:45Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder: [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> = Setting CPU frequency = Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px|center]] 2105480957ef39a4521a2a0299f9a7a0efa726de 2645 2644 2017-12-06T16:00:46Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder: [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> = Setting CPU frequency = Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px|center]] = Write the application = Go back into Xilinx SDK and refresh(F5). All the added files should now be visible in the project explorer. e720ae276413a310aa6a02fa100e619ae9bd0e3e 2647 2645 2017-12-06T17:01:26Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> platform.c<br /> platform.h<br /> printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder: [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> = Setting CPU frequency = Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px|center]] = Write the application = Go back into Xilinx SDK and refresh(F5). All the added files should now be visible in the project explorer. ffd47fd8ebcfc09314a078e8daf6201bf3f4db9f 2650 2647 2017-12-06T17:26:22Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> platform.c<br /> platform.h<br /> platform_config.h printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder: [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> = Setting CPU frequency = Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px|center]] = Write the application = Go back into Xilinx SDK and refresh(F5). All the added files should now be visible in the project explorer. Open main.c, and comment out the call to ''vParTestInitialise()'' from the ''prvSetupHardware'' function as it is not related to the Zybo board. Also comment out all the included headerfiles under "Standard Demo Include:<br /> [[File:remove_include_demo_libs.png|400px|center]]<br /> Also set ''#define mainSELECTED_APPLICATION 0'' instead of 1. It should be located around line 141. e210c9b090e948c1225ec4e66b4769a5a99a131e 2653 2650 2017-12-06T17:44:53Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. Tutorial heavily based on: #REDIRECT [[http://rishifranklin.blogspot.no/2015/04/freertos-on-xilinx-zynq-zybo-single-core.html]] This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> platform.c<br /> platform.h<br /> platform_config.h printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder: [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> = Setting CPU frequency = Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px|center]] = Write the application = Go back into Xilinx SDK and refresh(F5). All the added files should now be visible in the project explorer. Open main.c, and comment out the call to ''vParTestInitialise()'' from the ''prvSetupHardware'' function as it is not related to the Zybo board. Also comment out all the included headerfiles under "Standard Demo Include:<br /> [[File:remove_include_demo_libs.png|400px|center]]<br /> Also set ''#define mainSELECTED_APPLICATION 0'' instead of 1. It should be located around line 141. Add ''#define AXI_LED_BASE 0x43c30000'' somewhere in the top of the code, but not within any functions, for example right after all the #includes. Time to write the actual code. Add the following as a function before main: [[File:AXILedBlink_code.png|400px|center]]<br /> <br /> The last thing we need to do code vise, is to call the function we just created in the main function: [[File:main_code.png|400px|center]]<br /> <br /> Save, then goto ''Project --> Build All''. Time to test the software! Bring up your favorite Xilinx Zybo SoC board, and ensure that jumper 5 (JP5) is configured for booting via JTAG. Connect the board to the computer, and power it up. Then in Xilinx SDK, goto ''Xilinx --> Program FPGA''. If successful, goto ''Run --> Run as --> 1 Launch on Hardware (System Debugger)''. The 4 LEDs on the board should now light up and blink. End of tutorial! 7e740395373adda96f2e7eee1c89b203b396da1c 0 25 2630 2575 2017-12-06T13:29:31Z Yag005 96 wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[FreeRTOS]] Free Real Time Operating System * [[Vivado]] Xilinx Vivado == Andre fagressurser og laboratorieveiledninger== * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] 0870724ffc107bbd35dfbda61c61b380dd0e2984 2659 2630 2018-01-04T14:27:58Z Yag005 96 Added Xilinx to comply with readability criteria. wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Xilinx === * [[Vivado]] Xilinx Vivado * [[SDK]] Xilinx Software Development Kit === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[FreeRTOS]] Free Real Time Operating System == Andre fagressurser og laboratorieveiledninger== * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] 88ac289fe1e65816d5b676d92b820cfdaa2a6e7e 2661 2659 2018-01-04T14:30:22Z Yag005 96 wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Xilinx === * [[Xilinx Vivado]] Tutorials for Xilinx Vivado * [[Xilinx SDK]] Tutorials for Xilinx Software Development Kit === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[FreeRTOS]] Free Real Time Operating System == Andre fagressurser og laboratorieveiledninger== * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] f47579d2c53a92386d52211f08f8c9dccdf23ec7 6 649 2637 2017-12-06T15:23:38Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2646 2637 2017-12-06T16:04:11Z Yag005 96 Yag005 uploaded a new version of [[File:Source folder.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 2648 2646 2017-12-06T17:05:49Z Yag005 96 Yag005 uploaded a new version of [[File:Source folder.png]] wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 650 2639 2017-12-06T15:39:41Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 651 2640 2017-12-06T15:46:43Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 652 2641 2017-12-06T15:51:30Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 653 2649 2017-12-06T17:24:00Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 654 2651 2017-12-06T17:32:58Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 655 2652 2017-12-06T17:35:42Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 656 2654 2017-12-06T17:49:01Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 657 2655 2017-12-06T17:53:30Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 659 2662 2018-01-04T14:31:21Z Yag005 96 Created page with "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]" wikitext text/x-wiki [[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]] 8cd5d1141749af1af3e75db16716fa2c58da38c4 0 660 2663 2018-01-04T14:32:00Z Yag005 96 Created page with "[[Running concurrent application projects in Xilinx SDK]]" wikitext text/x-wiki [[Running concurrent application projects in Xilinx SDK]] 91a879a9b25c3750e1eeeb76c6fa1ac848f56c61 6 661 2664 2018-01-04T15:08:06Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 6 662 2665 2018-01-04T15:17:11Z Yag005 96 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 663 2666 2018-01-04T15:19:13Z Yag005 96 Created page with "Tested on Xilinx SDK 2017.4, with Xilinx Digilent Zybo SoC. = Running concurrent application projects in Xilinx SDK = This tutorial gives a brief introduction to running conc..." wikitext text/x-wiki Tested on Xilinx SDK 2017.4, with Xilinx Digilent Zybo SoC. = Running concurrent application projects in Xilinx SDK = This tutorial gives a brief introduction to running concurrent application projects in Xilinx SDK on a micro processor. This is done by assigning each of the Application Projects a specific processor core to run on. = Requirements = This tutorial requires a multi-core micro processor system that can be programmed by Xilinx SDK. It also assumes that the user has two working independent Project applications with respective Board Support Packages (BSP's) generated by the "File --> New --> Project Application" menu. = Assigning application project to specific processor core = Click once on one of the Application projects in the Project Explorer Tree. Goto: "Run --> Run Configurations". Then click on "System Debugger using Debug_standalone_bsp_0_NAMEOFYOURPROJECT.elf on Local" under "Xilinx C/C++ application (SystemDebugger). Then open the Application tab. You should now see that your application is configured in the Summary window to run on core 0 on whatever processor you're using. [[File:running_concurrent_xilinx_sdk_not_added.png|400px|thumbnail]] The next step is to take use of the other processor core, by assigning it the other application project you want to run. Click on the line with the processor core you want to use (ps7_cortexa9_1 for this tutorial), mark "Download", and click on Browse in the Application bar. Find the nameofproject.elf file for the application project, usually found under /NameOfVivadoProject.sdk/NameOfProject/Debug/NameOfProject.elf. For this tutorial we added the FreeRTOS.elf created in the [[Running FreeRTOS on Xilinx Zybo]]-tutorial. It should now look like this: [[File:running_concurrent_xilinx_sdk_added.png|400px|thumbnail]] Click Apply, and run. This should program the processor over JTAG, and both applications should be up and running. 08e612da9975f43fcf1758b81c527716faf27215 2667 2666 2018-01-04T15:19:45Z Yag005 96 wikitext text/x-wiki Tested on Xilinx SDK 2017.4, with Xilinx Digilent Zybo SoC. = Running concurrent application projects in Xilinx SDK = This tutorial gives a brief introduction to running concurrent application projects in Xilinx SDK on a micro processor. This is done by assigning each of the Application Projects a specific processor core to run on. = Requirements = This tutorial requires a multi-core micro processor system that can be programmed by Xilinx SDK. It also assumes that the user has two working independent Project applications with respective Board Support Packages (BSP's) generated by the "File --> New --> Project Application" menu. = Assigning application project to specific processor core = Click once on one of the Application projects in the Project Explorer Tree. Goto: "Run --> Run Configurations". Then click on "System Debugger using Debug_standalone_bsp_0_NAMEOFYOURPROJECT.elf on Local" under "Xilinx C/C++ application (SystemDebugger). Then open the Application tab. You should now see that your application is configured in the Summary window to run on core 0 on whatever processor you're using. [[File:running_concurrent_xilinx_sdk_not_added.png|400px|thumbnail|center]] The next step is to take use of the other processor core, by assigning it the other application project you want to run. Click on the line with the processor core you want to use (ps7_cortexa9_1 for this tutorial), mark "Download", and click on Browse in the Application bar. Find the nameofproject.elf file for the application project, usually found under /NameOfVivadoProject.sdk/NameOfProject/Debug/NameOfProject.elf. For this tutorial we added the FreeRTOS.elf created in the [[Running FreeRTOS on Xilinx Zybo]]-tutorial. It should now look like this: [[File:running_concurrent_xilinx_sdk_added.png|400px|thumbnail|center]] Click Apply, and run. This should program the processor over JTAG, and both applications should be up and running. d5d69c6d381aa1dc14d7cc92814bce9e94a8f842 0 647 2668 2653 2018-01-09T13:58:17Z Yag005 96 wikitext text/x-wiki Tested on Xilinx Vivado/SDK 2017.3, Ubuntu 16.04 LTS. Tutorial heavily based on: #REDIRECT [[http://rishifranklin.blogspot.no/2015/04/freertos-on-xilinx-zynq-zybo-single-core.html]] This tutorial assumes you have completed the "[[Creating example project with AXI4 Lite peripheral in Xilinx Vivado]]"-tutorial. = Running FreeRTOS on Xilinx Zybo = This tutorial will help in setting up Xilinx Zybo SoC-board to run FreeRTOS with an example project that toggles the LEDs on the board. It assumes that the user has successfully exported the hardware bitstream from the Xilinx Vivado project created in the previous tutorial linked at the top. = Setup SDK = Launch Xilinx SDK from the project in Xilinx Vivado: ''File --> Launch SDK''. Create a new application project with ''File --> New --> Application Project'' and name it "FreeRTOS_example_project". Use C as language, standalone as OS. Click next, select "Empty Application", and finish. = Acquire FreeRTOS = Download and extract FreeRTOS available at the FreeRTOS homepage: #Homepage [[https://www.freertos.org/a00104.html]]<br /> = Add FreeRTOS to the project = Open the extracted folder, and copy the following files into the SDK project source folder located at: \axi3_lite_tutorial_project\axi4_lite_tutorial_project.sdk\FreeRTOS_example_project\src\ \FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\<br /> FreeRTOS_asm_vectors.S<br /> FreeRTOSConfig.h<br /> FreeRTOS_tick_config.c<br /> main.c<br /> platform.c<br /> platform.h<br /> platform_config.h printf-stdarg.c<br /> <br /> \FreeRTOSV8.2.1\FreeRTOS\Source\<br /> croutine.c<br /> event_groups.c<br /> list.c<br /> queue.c<br /> tasks.c<br /> timers.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\include\<br /> croutine.h<br /> deprecated_definitions.h<br /> event_groups.h<br /> FreeRTOS.h<br /> list.h<br /> mpu_prototypes.h<br /> mpu_wrappers.h<br /> portable.h<br /> projdefs.h<br /> queue.h<br /> semphr.h<br /> StackMacros.h<br /> task.h<br /> timers.h<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\MemMang\<br /> heap_4.c<br /><br /> \FreeRTOSV8.2.1\FreeRTOS\Source\portable\GCC\ARM_CA9\<br /> port.c<br /> portASM.S<br /> portmacro.h<br /> <br /> Your SDK project source folder should now look like this: [[File:source_folder.png|thumbnail|center]]<br /> Edit the highlighted line to the lscript.id file located in the SDK project source folder to contain "*(.freertos_vectors)": [[File:lscript_id_edit.png|400px|center]]<br /> Comment out "*pxTopOfStack |= portTHUMB_MODE_BIT;" on line 280 in port.c to avoid FreeRTOS to run in thumb-mode: [[File:port_c_edit.png|400px|center]]<br /> <br /> = Setting CPU frequency = Next we should configure the CPU to run at 50MHz in the FreeRTOSConfig.h file by editing the configCPU_CLOCK_HZ parameter: [[File:FreeRTOSConfig_cpu_freq_edit.png|400px|center]] = Write the application = Go back into Xilinx SDK and refresh(F5). All the added files should now be visible in the project explorer. Open main.c, and comment out the call to ''vParTestInitialise()'' from the ''prvSetupHardware'' function as it is not related to the Zybo board. Also comment out all the included headerfiles under "Standard Demo Include:<br /> [[File:remove_include_demo_libs.png|400px|center]]<br /> Also set ''#define mainSELECTED_APPLICATION 0'' instead of 1. It should be located around line 141. Add ''#define AXI_LED_BASE 0x43c30000'' somewhere in the top of the code, but not within any functions, for example right after all the #includes. Time to write the actual code. Add the following as a function before main: [[File:AXILedBlink_code.png|400px|center]]<br /> <br /> The last thing we need to do code vise, is to call the function we just created in the main function: [[File:main_code.png|400px|center]]<br /> <br /> Save, then goto ''Project --> Build All''. Time to test the software! Bring up your favorite Xilinx Zybo SoC board, and ensure that jumper 5 (JP5) is configured for booting via JTAG. Connect the board to the computer, and power it up. Then in Xilinx SDK, goto ''Xilinx --> Program FPGA''. If successful, goto ''Run --> Run as --> 1 Launch on Hardware (System Debugger)''. The 4 LEDs on the board should now light up and blink. End of tutorial! 57ef37cf885313d78740f1145256c8a27698e3e0 0 278 2669 2418 2018-01-12T10:33:39Z Mer020 87 wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://klabs.org/richcontent/Tutorial/tutorial.htm Tutorials for Programmable Logic and Military/Aerospace Systems] (broken link) * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Using Vivado ==== * [[Install Vivado 2015.4 with free licens]] * [[VGA controller VHDL code]] * [[Nexys4_Master.xdc]] * [[Using the VGA controller with block ram generator and clock wizard]] === Gamle øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] 73dde613fdce1d2153902105a6cf3ee4eaa9386e 0 572 2670 2411 2018-02-26T11:58:36Z Gge002 52 /* Regler for bruk av strålekilder på IFT */ wikitext text/x-wiki ==Førstegangsbrukere== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ==Regler for bruk av strålekilder på IFT== [[File:hierarket.jpg|thumb|alt=Hierarke|Fig. 1 Hierarke]] [[File:TableHeader.jpg|thumb|alt=Logbokformat|Fig. 2 Logbokformat]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. 2200b9f74fa1542522794ca8b5eaf3433932f507 2703 2670 2018-05-29T14:30:34Z Gge002 52 wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. c1321126d4841f1d5342bdd5977df92978971fa8 2711 2703 2018-11-16T10:43:39Z Gge002 52 wikitext 2712 2711 2018-11-16T11:12:06Z Gge002 52 wikitext 2713 2712 2018-11-16T11:15:13Z Gge002 52 wikitext 2714 2713 2018-11-16T11:47:10Z Gge002 52 wikitext 2715 2714 2018-11-16T11:58:34Z Gge002 52 wikitext 2716 2715 2018-11-16T12:11:07Z Gge002 52 wikitext 2717 2716 2018-11-16T12:28:41Z Gge002 52 wikitext 2718 2717 2018-11-16T12:30:18Z Gge002 52 wikitext 2719 2718 2018-11-16T12:40:18Z Gge002 52 wikitext 0 481 2671 2439 2018-03-08T13:18:14Z Put009 99 Corrected write and read signal names in set_inputs_passive and fixed dead link wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> The presentation can also be found in the uvvm_util folder. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wena <= '0'; sbi_if.rena <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] 92833b53eed35233a8271fe235015a1b73959906 0 189 2672 2323 2018-03-12T11:49:59Z Put009 99 Updated path to XJTAG 3.5 wikitext text/x-wiki =XJEase and XJDeveloper Tutorial= You should run the tutorial at Program Files> XJTAG 3.5 > Help > XJEase and XJDeveloper tutorial. The program this tutorial is designed for is called XJDeveloper 3.5. This tutorial assumes you have a version 3.1 of the XJDemo board. In the help folder there is a turtorial.zip file with the files you're going to use. Unzip this to a new folder for your project. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. On the 3.1 version you will see the name written on the card. [[Image:XJDemo v1.2.png|292px]][[Image:XJDemo v2.0.png|292px]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board. Refer to the schematic for the pinmapping for page 11 of the tutorial. # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. =Additional resources= [[XJTAG_for_new_prototypes]] [[Category:Mikroelektronikk]] 3c91aa6ce4a56fa5307e6ff85da6694fbe283e83 0 539 2673 2505 2018-03-12T14:14:52Z Put009 99 Link til intel si nedlastingsside for quartus og modelsim wikitext text/x-wiki Obs! Fra Quartus Prime Handbook: Gate-level timing simulation of an entire design can be slow and should be avoided. Gate-level timing simulation is supported only for the Stratix IV and Cyclone IV device families. Use TimeQuest static timing analysis rather than gate-level timing simulation. ===Syntetiseringen av VHDL kode=== Vi ønsker å syntisere koden for å lage beskrivelse av koden tilpasset en FPGA-chip. Vi skal først syntisere koden med Quartus. Deretter skal vi simulere denne koden og sammenligne med den opprinnelige koden uten timing-informasjon. Vi bruker en ALU som eksempel. Det er viktig at vi bruker Quartus og ModelSim fra samme utgivelse om vi ikke ønsker å kompilere våre egne simuleringsbibliotek. Du kan installere Quartus og ModelSim gratis og bruke lisens-server på UiB sitt nettverk. Vi bruker Quartus Prime 15.1 og ModelSim 10.4b. Quartus og Intel sin Modelsim versjon kan lastest ned [http://dl.altera.com/?product=modelsim_ae her]. ==Quartus== Lag et nytt prosjekt, kall det add_sub_alu og velg en passende mappe. Velg empty project, og deretter legg til add_sub_alu.vhd. Velg en CycloneIV-chip. Vi valgte EP4CE115F29. Det er chipen på Terasic DE2-115. Pass på at add_sub_alu.vhd er valgt som top-level og trykk så Start Compilation (Ctrl-L). Dette gjør at Quartus går gjennom alle stegene for å produsere filene vi er ute etter. I simulation/modelsim/ finner vi nå add_sub_alu.vho og add_sub_alu_vhd.sdo. Vho-filen(VHDL Output File) er filen som inneholder nå det opprinnelige designet, men også mange nye moduler med cycloneive-prefix. Disse entitetene beskriver ressurser på den fysiske FPGA-chipen. Sdo-filen(Standard Delay Format Output File) inneholder detaljer om delay fra hver modul på chippen. ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila for designet add_sub_alu.vhd og testbenken alu_tb.vhd. Så legg vi til fila som Quartus generte i prosjektdir til simulation/modelsim/add_sub_alu.vho. Den Quartus-genererte filen vil ha samme entitetsnavn som den opprinnelige, og vil derfor ikke kunne simuleres samtid. Vi endrer derfor den genererte filen til å ha entiteten 'add_sub_alu_synth' og architecturen 'structure' (i vårt tilfelle endret den seg til structure automatisk). Vi kan nå kompilere filene våre og deretter simulere testbenken. I testbenken vår ser vi at vi har kalt den syntiserte entiteten alu_synt. Dette skal vi bruke nå. ==Simulering med timing== Velg Start Simulation - deretter work og alu_tb. Se så på SDF-fanen. Legg til add_sub_alu_vhd.sdo generert av Quartus tidligere. Under apply to region må du skrive: /alu_tb/alu_synt Dette er altså området vi ønsker at sdo-filen skal gi informasjon om. Trykk så OK. add wave * run -all Vi kan nå sammenligne utsignalene for den usyntiserte og den syntiserte ALU-komponenten. ==Konklusjon== Vi ser at vi får masse feil før 50 ns. Dette skyldes at den opprinnelige komponenten ikke har definerte signaler før de første klokkeflankene, mens den syntiserte komponenten ikke kan ha udefinerte signaler. Senere får vi feil når signalene skifter. Dette skyldes at den syntiserte komponenten bruker lengre tid på å sende ut riktig signal, og vil også glitche mellom verdier før den stabiliserer seg på riktig verdi. ==Kode== ===Kode til add_sub_alu.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] [[Category:VHDL]] 6d186c7bc6487d0f96c10a3438b69035700a6a31 0 33 2674 2395 2018-03-13T12:38:41Z Put009 99 Updated a dead link wikitext text/x-wiki <!-- Mapping av alterabibliotek: <pre> vmap cyclonev /prog/altera/vhdl_libs/cyclonev vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> --> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] [[Synthese av VHDL - Oppdatert]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] <!-- [http://www.ashenden.com.au/ Ashenden Designs] dead link --> [http://freerangefactory.org/books_tuts.html Free Range VHDL textbook] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] <!-- [http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)] dead link --> [http://www.ioenotes.edu.np/media/notes/embedded-system/vhdl.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [http://bitvis.no/products/bitvis-utility-library/ Bitvis utility library] [[Category:Mikroelektronikk]] ade7d1bf7beb213b584207dce1815e43023fbfc6 2 608 2675 2572 2018-03-22T13:08:12Z Fli091 93 sandbox and category wikitext text/x-wiki [mailto:fli091@uib.no mailto:fli091@uib.no] == Sandbox == * [[User:Fli091/Print schematics with Cadence]] == Diverse lenker == * [https://www.eda.ncsu.edu/wiki/FreePDK The FreePDKTM process design kit is an open-source, Open-Access-based PDK for the 45nm technology] * [http://venividiwiki.ee.virginia.edu/mediawiki/index.php/ToolsCadenceTutorialsBasicSimulationOceanFreePDK Simulere med Cadence via OCEAN skript] * [https://drive.google.com/file/d/0B8aUrqN1GG-DMl9Mc29rQnRpaVE/edit En presentasjon av hvordan lage OCEANskript] [[Category:Microelectronics Users|FredrikLindseth]] ab4451ff9b9b693af2c8762533f6d615ed8f0202 6 665 2678 2018-03-22T13:45:11Z Fli091 93 A screenshot of the print-window in Cadence Virtuoso wikitext text/x-wiki A screenshot of the print-window in Cadence Virtuoso e3cfa7d51273ff59e4309c61acaffd7af59bf9b9 6 666 2679 2018-03-22T13:46:34Z Fli091 93 A screenshot showing the plot options window in Cadence Virtuoso wikitext text/x-wiki A screenshot showing the plot options window in Cadence Virtuoso e86ca7228e474497f6380caae27a77296dca4552 6 667 2684 2018-03-22T14:24:16Z Fli091 93 The output of the Cadence postscript-printer converted to jpg for showing on the wiki wikitext text/x-wiki The output of the Cadence postscript-printer converted to jpg for showing on the wiki 352edb1b8c0671a34a3d18b8e2b6f67092e822c1 0 668 2686 2018-03-22T14:28:35Z Fli091 93 Created page wikitext text/x-wiki = Print schematics from Cadence Virtuoso = This article will show you how to save your schematics in a vectorised format so they can be manipulated or embedded in a report or a thesis. Doing it this way, instead of "Export image" will result in something that looks useable and high resolution. It is based on this youtube-movie https://www.youtube.com/watch?v=JivgqYabhWI == Procedure == 1. Locate the file containing the plotter-setups. It comes with the technology package and is located here: /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit 2. Move the file to your own tsmc-folder mv /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit ~/tsmc/.cdsplotinit [[File:CadencePrintWindow.png|300px|thumb|right|The print-window in Virtuoso]] 3. Rename "your plotter": Change line 18, "Encapsulated PostScript:" to "p1|Encapsulated PostScript:" gedit ~/tsmc/.cdsplotinit or vim ~/tsmc/.cdsplotinit * If you get the error *Error* lessp: can't handle (nil <nil) you have to restart virtuoso for the plotters to be enabled 4. Now to print. First you might want to set a paper size. This is done here: File - Print - Plot Options ... - Paper Size Make sure the "Plotter Name" is what you called your plotter (p1). 5. Check the boxes "Fit to Page" and "Center plot" 6. Uncheck the the box "Mail Log To" and check the box "Send Plot Only To File" and set the path to where you want your plots/prints/schematics to be stored. This is also where you decide on a filename ~/tsmc/printedFromVirtuoso/voltageBuffer.ps [[File:CadencePlotOptions.png|300px|thumb|right|The plot options-window in Virtuoso]] 7. Make sure the folder you have set to save your files in exist or Virtuoso will just output a warning ala *WARNING* (SCH-1266): Cannot write to file "~/tsmc/printedFromVirtuoso/buffer.ps". Create the folder: mkdir ~/tsmc/printedFromVirtuoso/ 8. Click OK in the Plot Options windows 9. Uncheck the "Plot with: header" box, just above the notes window 10. Press OK to save the schematic. Now you can open the output.ps-file and it will look something like this: [[File:Shaper.ps.jpg|center|thumb|The output of the Cadence postscript-printer converted to jpg]] For the next schematics you want to plot you only have to "File - Print - Plot Options ...", change your filename and press OK. === Tips to make the schematic look better === ==== Disable all annotations ==== Do the following twice, once to enable this (and disable anything else) and the one more time to disable it again View - Annotations - Component Parameters This will make the schematic look cleaner and will hide fingers and channel lengths, etc. You could also do the same with net names, and possibly hide instance labels View - Hide Instance Labels ==== Wider lines ==== Open the outputfile (.ps) in a text editor and find setlinewidth This set the width of all lines and can be changed to i.e. 2 for wider lines. 2 setlinewidth Note: if you have text (not disabled annotations etc) the letters might mix together. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 93fe5d519ce7f9c9f67fbc247b37e446659fcd6f 2687 2686 2018-03-22T14:29:29Z Fli091 93 Formatting wikitext text/x-wiki = Print schematics from Cadence Virtuoso = This article will show you how to save your schematics in a vectorised format so they can be manipulated or embedded in a report or a thesis. Doing it this way, instead of "Export image" will result in something that looks useable and high resolution. It is based on this youtube-movie https://www.youtube.com/watch?v=JivgqYabhWI == Procedure == 1. Locate the file containing the plotter-setups. It comes with the technology package and is located here: /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit 2. Move the file to your own tsmc-folder mv /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit ~/tsmc/.cdsplotinit [[File:CadencePrintWindow.png|300px|thumb|right|The print-window in Virtuoso]] 3. Rename "your plotter": Change line 18, "Encapsulated PostScript:" to "p1|Encapsulated PostScript:" gedit ~/tsmc/.cdsplotinit or vim ~/tsmc/.cdsplotinit * If you get the error *Error* lessp: can't handle (nil <nil) you have to restart virtuoso for the plotters to be enabled 4. Now to print. First you might want to set a paper size. This is done here: File - Print - Plot Options ... - Paper Size Make sure the "Plotter Name" is what you called your plotter (p1). 5. Check the boxes "Fit to Page" and "Center plot" 6. Uncheck the the box "Mail Log To" and check the box "Send Plot Only To File" and set the path to where you want your plots/prints/schematics to be stored. This is also where you decide on a filename ~/tsmc/printedFromVirtuoso/voltageBuffer.ps [[File:CadencePlotOptions.png|300px|thumb|right|The plot options-window in Virtuoso]] 7. Make sure the folder you have set to save your files in exist or Virtuoso will just output a warning ala *WARNING* (SCH-1266): Cannot write to file "~/tsmc/printedFromVirtuoso/buffer.ps". Create the folder: mkdir ~/tsmc/printedFromVirtuoso/ 8. Click OK in the Plot Options windows 9. Uncheck the "Plot with: header" box, just above the notes window 10. Press OK to save the schematic. Now you can open the output.ps-file and it will look something like this: [[File:Shaper.ps.jpg|center|thumb|The output of the Cadence postscript-printer converted to jpg]] For the next schematics you want to plot you only have to "File - Print - Plot Options ...", change your filename and press OK. == Tips to make the schematic look better == === Disable all annotations === Do the following twice, once to enable this (and disable anything else) and the one more time to disable it again View - Annotations - Component Parameters This will make the schematic look cleaner and will hide fingers and channel lengths, etc. You could also do the same with net names, and possibly hide instance labels View - Hide Instance Labels === Wider lines === Open the outputfile (.ps) in a text editor and find setlinewidth This set the width of all lines and can be changed to i.e. 2 for wider lines. 2 setlinewidth Note: if you have text (not disabled annotations etc) the letters might mix together. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] f05cd60eab3d7a1a483361acdf9f20f77e8126f8 2688 2687 2018-03-22T14:46:49Z Fli091 93 /* Tips */ Papersize and conversion to other formats wikitext text/x-wiki = Print schematics from Cadence Virtuoso = This article will show you how to save your schematics in a vectorised format so they can be manipulated or embedded in a report or a thesis. Doing it this way, instead of "Export image" will result in something that looks useable and high resolution. It is based on this youtube-movie https://www.youtube.com/watch?v=JivgqYabhWI == Procedure == 1. Locate the file containing the plotter-setups. It comes with the technology package and is located here: /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit 2. Move the file to your own tsmc-folder mv /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit ~/tsmc/.cdsplotinit [[File:CadencePrintWindow.png|300px|thumb|right|The print-window in Virtuoso]] 3. Rename "your plotter": Change line 18, "Encapsulated PostScript:" to "p1|Encapsulated PostScript:" gedit ~/tsmc/.cdsplotinit or vim ~/tsmc/.cdsplotinit * If you get the error *Error* lessp: can't handle (nil <nil) you have to restart virtuoso for the plotters to be enabled 4. Now to print. First you might want to set a paper size. This is done here: File - Print - Plot Options ... - Paper Size Make sure the "Plotter Name" is what you called your plotter (p1). 5. Check the boxes "Fit to Page" and "Center plot" 6. Uncheck the the box "Mail Log To" and check the box "Send Plot Only To File" and set the path to where you want your plots/prints/schematics to be stored. This is also where you decide on a filename ~/tsmc/printedFromVirtuoso/voltageBuffer.ps [[File:CadencePlotOptions.png|300px|thumb|right|The plot options-window in Virtuoso]] 7. Make sure the folder you have set to save your files in exist or Virtuoso will just output a warning ala *WARNING* (SCH-1266): Cannot write to file "~/tsmc/printedFromVirtuoso/buffer.ps". Create the folder: mkdir ~/tsmc/printedFromVirtuoso/ 8. Click OK in the Plot Options windows 9. Uncheck the "Plot with: header" box, just above the notes window 10. Press OK to save the schematic. Now you can open the output.ps-file and it will look something like this: [[File:Shaper.ps.jpg|center|thumb|The output of the Cadence postscript-printer converted to jpg]] For the next schematics you want to plot you only have to "File - Print - Plot Options ...", change your filename and press OK. == Tips == === Disable all annotations === Do the following twice, once to enable this (and disable anything else) and the one more time to disable it again View - Annotations - Component Parameters This will make the schematic look cleaner and will hide fingers and channel lengths, etc. You could also do the same with net names, and possibly hide instance labels View - Hide Instance Labels === Wider lines === Open the outputfile (.ps) in a text editor and find setlinewidth This set the width of all lines and can be changed to i.e. 2 for wider lines. 2 setlinewidth Note: if you have text (not disabled annotations etc) the letters might mix together. === Sizing the "paper" === Changing the papersize from 5x5 to "unlimited" results in a larger plot, the filesize increased to 125%, but since PS is not a bitmap this is irrelevant as the schematic can be scaled to whatever size. === Convert the postscript(ps) to another format === On linux there are several tools that easily converts. For example ps2pdf output.ps output.pdf Results in a nice PDF to put in reports/theses. The conversion can also be changed to .png or .jpg [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 5d6c65fe12b90866bb345c370ee1647a45bd3608 2689 2688 2018-03-22T14:50:46Z Fli091 93 /* Convert the postscript(ps) to another format */ Save to File/PDF wikitext text/x-wiki = Print schematics from Cadence Virtuoso = This article will show you how to save your schematics in a vectorised format so they can be manipulated or embedded in a report or a thesis. Doing it this way, instead of "Export image" will result in something that looks useable and high resolution. It is based on this youtube-movie https://www.youtube.com/watch?v=JivgqYabhWI == Procedure == 1. Locate the file containing the plotter-setups. It comes with the technology package and is located here: /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit 2. Move the file to your own tsmc-folder mv /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit ~/tsmc/.cdsplotinit [[File:CadencePrintWindow.png|300px|thumb|right|The print-window in Virtuoso]] 3. Rename "your plotter": Change line 18, "Encapsulated PostScript:" to "p1|Encapsulated PostScript:" gedit ~/tsmc/.cdsplotinit or vim ~/tsmc/.cdsplotinit * If you get the error *Error* lessp: can't handle (nil <nil) you have to restart virtuoso for the plotters to be enabled 4. Now to print. First you might want to set a paper size. This is done here: File - Print - Plot Options ... - Paper Size Make sure the "Plotter Name" is what you called your plotter (p1). 5. Check the boxes "Fit to Page" and "Center plot" 6. Uncheck the the box "Mail Log To" and check the box "Send Plot Only To File" and set the path to where you want your plots/prints/schematics to be stored. This is also where you decide on a filename ~/tsmc/printedFromVirtuoso/voltageBuffer.ps [[File:CadencePlotOptions.png|300px|thumb|right|The plot options-window in Virtuoso]] 7. Make sure the folder you have set to save your files in exist or Virtuoso will just output a warning ala *WARNING* (SCH-1266): Cannot write to file "~/tsmc/printedFromVirtuoso/buffer.ps". Create the folder: mkdir ~/tsmc/printedFromVirtuoso/ 8. Click OK in the Plot Options windows 9. Uncheck the "Plot with: header" box, just above the notes window 10. Press OK to save the schematic. Now you can open the output.ps-file and it will look something like this: [[File:Shaper.ps.jpg|center|thumb|The output of the Cadence postscript-printer converted to jpg]] For the next schematics you want to plot you only have to "File - Print - Plot Options ...", change your filename and press OK. == Tips == === Disable all annotations === Do the following twice, once to enable this (and disable anything else) and the one more time to disable it again View - Annotations - Component Parameters This will make the schematic look cleaner and will hide fingers and channel lengths, etc. You could also do the same with net names, and possibly hide instance labels View - Hide Instance Labels === Wider lines === Open the outputfile (.ps) in a text editor and find setlinewidth This set the width of all lines and can be changed to i.e. 2 for wider lines. 2 setlinewidth Note: if you have text (not disabled annotations etc) the letters might mix together. === Sizing the "paper" === Changing the papersize from 5x5 to "unlimited" results in a larger plot, the filesize increased to 125%, but since PS is not a bitmap this is irrelevant as the schematic can be scaled to whatever size. === Convert the postscript(ps) to another format === On linux there are several tools that easily converts. For example ps2pdf output.ps output.pdf Results in a nice PDF to put in reports/theses. The conversion can also be changed to .png or .jpg An alternative way to convert is to open the outpus.ps in a PDF viewer. Choose "Print" and "Print to File" and save the file as a PDF. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] d1755e7bad665b4ba67a2540bdf875975c399ef5 2690 2689 2018-03-24T12:47:17Z Fli091 93 /* Convert the postscript(ps) to another format */ epstopdf conversion and whitespace around schematics wikitext text/x-wiki = Print schematics from Cadence Virtuoso = This article will show you how to save your schematics in a vectorised format so they can be manipulated or embedded in a report or a thesis. Doing it this way, instead of "Export image" will result in something that looks useable and high resolution. It is based on this youtube-movie https://www.youtube.com/watch?v=JivgqYabhWI == Procedure == 1. Locate the file containing the plotter-setups. It comes with the technology package and is located here: /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit 2. Move the file to your own tsmc-folder mv /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit ~/tsmc/.cdsplotinit [[File:CadencePrintWindow.png|300px|thumb|right|The print-window in Virtuoso]] 3. Rename "your plotter": Change line 18, "Encapsulated PostScript:" to "p1|Encapsulated PostScript:" gedit ~/tsmc/.cdsplotinit or vim ~/tsmc/.cdsplotinit * If you get the error *Error* lessp: can't handle (nil <nil) you have to restart virtuoso for the plotters to be enabled 4. Now to print. First you might want to set a paper size. This is done here: File - Print - Plot Options ... - Paper Size Make sure the "Plotter Name" is what you called your plotter (p1). 5. Check the boxes "Fit to Page" and "Center plot" 6. Uncheck the the box "Mail Log To" and check the box "Send Plot Only To File" and set the path to where you want your plots/prints/schematics to be stored. This is also where you decide on a filename ~/tsmc/printedFromVirtuoso/voltageBuffer.ps [[File:CadencePlotOptions.png|300px|thumb|right|The plot options-window in Virtuoso]] 7. Make sure the folder you have set to save your files in exist or Virtuoso will just output a warning ala *WARNING* (SCH-1266): Cannot write to file "~/tsmc/printedFromVirtuoso/buffer.ps". Create the folder: mkdir ~/tsmc/printedFromVirtuoso/ 8. Click OK in the Plot Options windows 9. Uncheck the "Plot with: header" box, just above the notes window 10. Press OK to save the schematic. Now you can open the output.ps-file and it will look something like this: [[File:Shaper.ps.jpg|center|thumb|The output of the Cadence postscript-printer converted to jpg]] For the next schematics you want to plot you only have to "File - Print - Plot Options ...", change your filename and press OK. == Tips == === Disable all annotations === Do the following twice, once to enable this (and disable anything else) and the one more time to disable it again View - Annotations - Component Parameters This will make the schematic look cleaner and will hide fingers and channel lengths, etc. You could also do the same with net names, and possibly hide instance labels View - Hide Instance Labels === Wider lines === Open the outputfile (.ps) in a text editor and find setlinewidth This set the width of all lines and can be changed to i.e. 2 for wider lines. 2 setlinewidth Note: if you have text (not disabled annotations etc) the letters might mix together. === Sizing the "paper" === Changing the papersize from 5x5 to "unlimited" results in a larger plot, the filesize increased to 125%, but since PS is not a bitmap this is irrelevant as the schematic can be scaled to whatever size. === Convert the postscript(ps) to another format === On linux there are several tools that easily converts. For example ps2pdf output.ps output.pdf or epstopdf outpus.ps Results in a nice PDF to put in reports/theses. The conversion can also be changed to .png or .jpg An alternative way to convert is to open the outpus.ps in a PDF viewer. Choose "Print" and "Print to File" and save the file as a PDF. Note: some of these conversion might put the postscript-file on a large A4-paper with whitespace all around. Try epstopdf if this happens, it does not do that. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 09a92d073a6474a23b4f566638b43e1e7511af00 2691 2690 2018-03-24T12:47:33Z Fli091 93 /* Convert the postscript(ps) to another format */ typo wikitext text/x-wiki = Print schematics from Cadence Virtuoso = This article will show you how to save your schematics in a vectorised format so they can be manipulated or embedded in a report or a thesis. Doing it this way, instead of "Export image" will result in something that looks useable and high resolution. It is based on this youtube-movie https://www.youtube.com/watch?v=JivgqYabhWI == Procedure == 1. Locate the file containing the plotter-setups. It comes with the technology package and is located here: /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit 2. Move the file to your own tsmc-folder mv /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit ~/tsmc/.cdsplotinit [[File:CadencePrintWindow.png|300px|thumb|right|The print-window in Virtuoso]] 3. Rename "your plotter": Change line 18, "Encapsulated PostScript:" to "p1|Encapsulated PostScript:" gedit ~/tsmc/.cdsplotinit or vim ~/tsmc/.cdsplotinit * If you get the error *Error* lessp: can't handle (nil <nil) you have to restart virtuoso for the plotters to be enabled 4. Now to print. First you might want to set a paper size. This is done here: File - Print - Plot Options ... - Paper Size Make sure the "Plotter Name" is what you called your plotter (p1). 5. Check the boxes "Fit to Page" and "Center plot" 6. Uncheck the the box "Mail Log To" and check the box "Send Plot Only To File" and set the path to where you want your plots/prints/schematics to be stored. This is also where you decide on a filename ~/tsmc/printedFromVirtuoso/voltageBuffer.ps [[File:CadencePlotOptions.png|300px|thumb|right|The plot options-window in Virtuoso]] 7. Make sure the folder you have set to save your files in exist or Virtuoso will just output a warning ala *WARNING* (SCH-1266): Cannot write to file "~/tsmc/printedFromVirtuoso/buffer.ps". Create the folder: mkdir ~/tsmc/printedFromVirtuoso/ 8. Click OK in the Plot Options windows 9. Uncheck the "Plot with: header" box, just above the notes window 10. Press OK to save the schematic. Now you can open the output.ps-file and it will look something like this: [[File:Shaper.ps.jpg|center|thumb|The output of the Cadence postscript-printer converted to jpg]] For the next schematics you want to plot you only have to "File - Print - Plot Options ...", change your filename and press OK. == Tips == === Disable all annotations === Do the following twice, once to enable this (and disable anything else) and the one more time to disable it again View - Annotations - Component Parameters This will make the schematic look cleaner and will hide fingers and channel lengths, etc. You could also do the same with net names, and possibly hide instance labels View - Hide Instance Labels === Wider lines === Open the outputfile (.ps) in a text editor and find setlinewidth This set the width of all lines and can be changed to i.e. 2 for wider lines. 2 setlinewidth Note: if you have text (not disabled annotations etc) the letters might mix together. === Sizing the "paper" === Changing the papersize from 5x5 to "unlimited" results in a larger plot, the filesize increased to 125%, but since PS is not a bitmap this is irrelevant as the schematic can be scaled to whatever size. === Convert the postscript(ps) to another format === On linux there are several tools that easily converts. For example ps2pdf output.ps output.pdf or epstopdf output.ps Results in a nice PDF to put in reports/theses. The conversion can also be changed to .png or .jpg An alternative way to convert is to open the outpus.ps in a PDF viewer. Choose "Print" and "Print to File" and save the file as a PDF. Note: some of these conversion might put the postscript-file on a large A4-paper with whitespace all around. Try epstopdf if this happens, it does not do that. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 465062aeb12f1172802b5ba8224462e19054deb3 2692 2691 2018-03-24T13:51:06Z Fli091 93 /* Tips */ =Using the schematics in latex= wikitext text/x-wiki = Print schematics from Cadence Virtuoso = This article will show you how to save your schematics in a vectorised format so they can be manipulated or embedded in a report or a thesis. Doing it this way, instead of "Export image" will result in something that looks useable and high resolution. It is based on this youtube-movie https://www.youtube.com/watch?v=JivgqYabhWI == Procedure == 1. Locate the file containing the plotter-setups. It comes with the technology package and is located here: /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit 2. Move the file to your own tsmc-folder mv /eda/cadence/2016-17/RHELx86/IC_6.1.7.704/tools.lnx86/plot/etc/cdsplotinit ~/tsmc/.cdsplotinit [[File:CadencePrintWindow.png|300px|thumb|right|The print-window in Virtuoso]] 3. Rename "your plotter": Change line 18, "Encapsulated PostScript:" to "p1|Encapsulated PostScript:" gedit ~/tsmc/.cdsplotinit or vim ~/tsmc/.cdsplotinit * If you get the error *Error* lessp: can't handle (nil <nil) you have to restart virtuoso for the plotters to be enabled 4. Now to print. First you might want to set a paper size. This is done here: File - Print - Plot Options ... - Paper Size Make sure the "Plotter Name" is what you called your plotter (p1). 5. Check the boxes "Fit to Page" and "Center plot" 6. Uncheck the the box "Mail Log To" and check the box "Send Plot Only To File" and set the path to where you want your plots/prints/schematics to be stored. This is also where you decide on a filename ~/tsmc/printedFromVirtuoso/voltageBuffer.ps [[File:CadencePlotOptions.png|300px|thumb|right|The plot options-window in Virtuoso]] 7. Make sure the folder you have set to save your files in exist or Virtuoso will just output a warning ala *WARNING* (SCH-1266): Cannot write to file "~/tsmc/printedFromVirtuoso/buffer.ps". Create the folder: mkdir ~/tsmc/printedFromVirtuoso/ 8. Click OK in the Plot Options windows 9. Uncheck the "Plot with: header" box, just above the notes window 10. Press OK to save the schematic. Now you can open the output.ps-file and it will look something like this: [[File:Shaper.ps.jpg|center|thumb|The output of the Cadence postscript-printer converted to jpg]] For the next schematics you want to plot you only have to "File - Print - Plot Options ...", change your filename and press OK. == Tips == === Disable all annotations === Do the following twice, once to enable this (and disable anything else) and the one more time to disable it again View - Annotations - Component Parameters This will make the schematic look cleaner and will hide fingers and channel lengths, etc. You could also do the same with net names, and possibly hide instance labels View - Hide Instance Labels === Wider lines === Open the outputfile (.ps) in a text editor and find setlinewidth This set the width of all lines and can be changed to i.e. 2 for wider lines. 2 setlinewidth Note: if you have text (not disabled annotations etc) the letters might mix together. === Sizing the "paper" === Changing the papersize from 5x5 to "unlimited" results in a larger plot, the filesize increased to 125%, but since PS is not a bitmap this is irrelevant as the schematic can be scaled to whatever size. === Using the schematics in latex === I recommend converting the ps-files to PDF it you want to use them in a latex-document. The ps can't be used directly and would have to be converted to eps, and since one is already converting PDF is a better choice. The converted PDF files are also 1/3 to 1/4 the size of the ps- and the eps-files and can be used without hassle as long as one uses the \usepackage{graphicx}-package. and the include the graphics like so \begin{figure}[ptbh!] \centering \includegraphics[width=0.5\textwidth]{pictures/nmos_folded_cascode.pdf} \caption{Folded cascode amplifier with NMOS input transistor.}\label{fig:foldedCascode} \end{figure} === Convert the postscript(ps) to another format === On linux there are several tools that easily converts. For example epstopdf output.ps or ps2pdf output.ps output.pdf Results in a nice PDF to put in reports/theses. With ps2pdf the conversion can also be changed to output .png or .jpg An alternative way to convert is to open the output.ps in a PDF viewer. Choose "Print" and "Print to File" and save the file as a PDF. Note: some of these conversion might put the postscript-file on a large A4-paper with whitespace all around. Try epstopdf if this happens, it does not do that. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 6a46dbd29b525c1dc8696801f66e6e57b7d81d14 0 461 2693 2531 2018-04-11T11:46:17Z Put009 99 Moved launch ade gxl from entering to simulation wikitext text/x-wiki =Cadence design with TSMC 130nm process= This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ==Setup of Cadence== To start virtuoso one must first connect to mikroserver3 ssh -X mikroserver3 '''First''' time you should add the following line to your cds.lib-file by running this command: mkdir ~/tsmc echo "DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf" > ~/tsmc/cds.lib Then ('''each time''') run these commands to set up Cadence source /eda/cadence/2016-17/scripts/analog_flow.sh source /eda/cadence/eda_general_init.sh Virtuoso Mixed Signal Design Environment is started by issuing this command: virtuoso & === Troubleshooting === * Make sure you source the script from the correct year. I.e 2016-17 and not 2015-16 * Make sure you are connected the the right mikroserver * Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/tsmc/') == Getting started == In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. ==Simulating the design== # Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] # Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 32ac2abe3eec95852a63a22b9d876bb52b496c8e 2694 2693 2018-04-11T13:33:24Z Put009 99 wikitext text/x-wiki =Cadence design with TSMC 130nm process= This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ==Setup of Cadence== To start virtuoso one must first connect to mikroserver3 ssh -X mikroserver3 '''First''' time you should add the following line to your cds.lib-file by running this command: mkdir ~/tsmc echo "DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf" > ~/tsmc/cds.lib Then ('''each time''') run these commands to set up Cadence source /eda/cadence/2016-17/scripts/analog_flow.sh source /eda/cadence/eda_general_init.sh Virtuoso Mixed Signal Design Environment is started by issuing this command: virtuoso & === Troubleshooting === * Make sure you source the script from the correct year. I.e 2016-17 and not 2015-16 * Make sure you are connected the the right mikroserver * Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/tsmc/') == Getting started == In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. ==Simulating the design== # Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] ea87904fbd4c82befb39e05fd0e1c420d96e5b18 2710 2694 2018-11-06T09:50:53Z Put009 99 Added if IHP are used, use SG13_dev technology wikitext text/x-wiki =Cadence design with TSMC 130nm process= This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ==Setup of Cadence== To start virtuoso one must first connect to mikroserver3 ssh -X mikroserver3 '''First''' time you should add the following line to your cds.lib-file by running this command: mkdir ~/tsmc echo "DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf" > ~/tsmc/cds.lib Then ('''each time''') run these commands to set up Cadence source /eda/cadence/2016-17/scripts/analog_flow.sh source /eda/cadence/eda_general_init.sh Virtuoso Mixed Signal Design Environment is started by issuing this command: virtuoso & === Troubleshooting === * Make sure you source the script from the correct year. I.e 2016-17 and not 2015-16 * Make sure you are connected the the right mikroserver * Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/tsmc/') == Getting started == In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. ==Simulating the design== # Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 7acba97a819f4625dac1ff70cb857b375096144f 0 478 2695 2512 2018-04-21T17:01:31Z Put009 99 Added simulation procedure wikitext text/x-wiki = Simulate with corner cases = To simulate with the corner cases in the fabrication process you have to add the corner files provided in the design kit. [[File:Selection_001.png|200px]] Choose "Click to add corner" "Click to add" the model files you need. Ex. The corner files for the MOS transistor in IHP130nm process is located in $IHP_TECH/tech/SG13_MOS/library/spectre/cornerMOSlv_psp.scs After adding the model files needed proceed by adding multiple corners: [[File:corner.png|400px]] The model files contains sections with the different corners. Choose sections and make sure you enable the section "tick box" and name the corner with a corresponding name: [[File:sections.png|400px]] The corners setup also makes it possible to simulate for different temperatures or design variables like VDD and transistor length. Ex. test for three different temperatures with comma as separation: -20,30,80 [[File:complete.png|400px]] To the do the simulation take a look at the "Data View" tab again. Make sure you have selected the corners, the desired test and global variables, and that they have the correct value. Then at the drop down menu in the toolbar, where stand "Single Run, Sweeps and Corners" click the light green play button. This will run the selected test, with your parameter values and selected corners. Wait for the simulation to complete, and then you can plot different corners, or use the "Plot All" button to get all corners plotted. [[Category:Mikroelektronikk]] 9aa8533ae3f0f06082ded5802ec82050cee01ccb 0 614 2696 2563 2018-04-21T17:17:17Z Put009 99 Added command for copying folders wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no == SSH key == * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no == Connection aliases == For ease of use set up aliases for the connections in your terminal. Open .bashrc in a text editor (vim / nano) and type in this alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no' alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no' alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no' Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc == Automatic sourcing == Source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2016-17/scripts/analog_flow.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc == Commands to run virtuoso remotely == Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3.ift.uib.no/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/fredrik/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to * this will copy the file to your home folder on any UiB machine * To copy a folder scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] a6ff7e3c7a0b7c9ddd8d2196fe061f055a8bc371 6 669 2697 2018-05-03T08:52:49Z Put009 99 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 670 2698 2018-05-04T11:43:10Z Put009 99 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 671 2699 2018-05-04T15:00:27Z Put009 99 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 672 2700 2018-05-04T15:28:55Z Put009 99 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 546 2701 2501 2018-05-04T15:47:57Z Put009 99 Added Parasitic extraction QRC and Post Layout Simulation wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. The user guide "SG13_user_guide.pdf" can be also be found in the folder "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/doc/pdf" on the microserver. [[File:Documentation.png|200px]] If your laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus QRC. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". The run the QRC. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. [[Category:Mikroelektronikk]] 30b98e9fbc148495581448e29f554f84d72e7442 6 673 2702 2018-05-29T13:29:58Z Gge002 52 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 234 2704 2537 2018-08-17T11:19:39Z Nfyst 67 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 61f85b84f5fda6304005aa5a99c947fe717832ab 0 202 2705 2360 2018-08-23T08:24:06Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [http://www.k-state.edu/ksuedl/publications/Technote%201%20-%20Equivalent%20Noise%20Bandwidth.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] 82b90d34acc1116e07d68a16e20bd7c337cb0a2a 2706 2705 2018-09-13T08:49:03Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://microscopy.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] 72e0882234deb6e4d1ca56da912661c0ad5274e5 2707 2706 2018-09-13T08:52:08Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [http://www.elsevierdirect.com/companion.jsp?ISBN=9781558605572 Logical Effort book web] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] a71db79a1c659e54edf42d67bf59524bf0f65946 2708 2707 2018-09-13T09:10:10Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] 48c1e5df48e085c02e1cf1256aaa7ab732a38e13 0 568 2709 2438 2018-10-30T12:07:54Z Nfyku 4 Changed from gitlab to git.app wikitext text/x-wiki == Software repository == We use the '''git.app''' server hosted by IT of University of Bergen. Further information: * [https://docs.gitlab.com/ce/gitlab-basics/README.html Gitlab basics] * [https://docs.gitlab.com/ee/workflow/README.html Gitlab workflow] == Development workflow == Every logged-in user can access the main repository, however only a small group of administrators has write access. To contribute, a user creates a ''fork'' from the repository. This is a copy where a single developer or a group of developers have full access. The main repository has the following branches: * '''production''': the latest production code, in this branch we have release tags * '''master''': the latest stable release * '''dev''': the development branch In addition to those main branches there can be ''feature'' branches where development happens detached from the main branches. A ''feature'' branch is based on the ''dev'' branch and has a limited lifetime. === Creating a project fork === A ''project fork'' or ''repository fork'' is a copy of the original repository where a user or a group of users has/have full control. All development in our project is carried out in the individual forks. Branches of project forks are merged back into the main repository by '''merge requests''', preferably via '''fast forward''' merges. That requires developers to rebase project forks to the main repository and resolve all conflicts before requesting a merge. [https://docs.gitlab.com/ce/gitlab-basics/fork-project.html How to fork a project] Your repository fork is your sandbox, you can do whatever you want. Unless you have your own rules at hand right now you can apply the following: * leave the ''master'' branch in sync with the main repository, do not make commits to it * commit your changes to the ''dev'' branch * if you start a new feature, and it's expected to take a while, make a ''feature'' branch, e.g. ''dev-feature'' and give the feature a name * synchronize regularly to the main repository by rebasing === Making local development copy === Clone directly from your development fork, replace ''user'' appropriately. '''Note''': the gitlab offers two modes for the link to be cloned, you can choose ''ssh'' (default setting) or ''https''. If you can not clone with the proposed default link, try option ''https://''. git clone https://user@git.app.uib.no/space/asdc.git This repository will get the name ''origin'' in your local clone. If you have cloned already from the main repository, the upstream link can be changed as follows cd <reponame> git remote set-url origin https://user@git.app.uib.no/asim/asdc.git === Pushing to development fork === Once you have added commits to e.g. the '''dev''' branch, those commits can be ''pushed'' upstream to the fork. git push origin dev === Pull/Merge request === All updates to the main repository are made via ''merge requests'' (github refers to them as ''pull requests''). A merge request requires the code update to be in a mergable branch in a development fork. Merge request are also used widely to share ''work-in-progress'' with your colleagues and for code reviews. Mark such Merge request with "'''WIP:'''". ==== Preparation ==== In order to avoid conflicts, first the fork has to be updated to the main repository. The idea behind this is that all potential conflicts can be resolved by the developer with the best knowledge about the matter, while the maintainer can simple merge ''fast-forward''. ==== Example workflow for a Merge request ==== # Go to your gitlab user space at [https://git.app.uib.no/user https://git.app.uib.no/user] (replace ''user'' appropriately. # Find the project fork, e.g. in the list of projects associated with you from the upper main menu. # In the line with the many columns regarding the repository, click on the "+"-symbol on the right hand side and choose "New merge request" # Select project and branch for both source and target, and click "Compare branches and continue" # Review the list of commits in this merge request, give it a descriptive title and description, pick an assignee # Submit the merge request === Importing an external package === The project will use a couple of external packages which are hosted in a different master repository. Copies of such external packages can be added to the gitlab server under our project group to provide a consistent package. Here is a proposed workflow for importing a package which is already hosted in git. # Create new repository in the asim group or ask for creation, lets call it ''newPackage'' # Fork the repository to your user space # Clone the package you want to import #:<pre> git clone <some_external_link> newPackage # we give it the new name</pre> #:<pre> cd newPackage</pre> # Redirect upstream URL to the fork in your gitlab user space #:<pre> git remote set-url origin https://user@git.app.uib.no/user/newPackage.git</pre> # Now make a forced push (option ''-f'') to import the repository to your fork #:<pre> git push -f origin</pre> # Create merge request to branch ''import'' (if not existing, ''master'' or any other appropriate branch) by following the instructions [[Documentation#Pull/Merge request | Pull/Merge request]] [[Category:Mikroelektronikk]] 3a354ea716def12b7187c2a9890def9d19705eef 0 572 2720 2719 2018-11-16T12:55:19Z Gge002 52 wikitext 2721 2720 2018-11-16T13:01:23Z Gge002 52 wikitext 2722 2721 2018-11-16T13:16:44Z Gge002 52 wikitext 2723 2722 2018-11-16T13:18:15Z Gge002 52 wikitext 2724 2723 2018-11-16T13:58:24Z Gge002 52 wikitext 2725 2724 2018-11-16T14:16:48Z Gge002 52 wikitext 2726 2725 2018-11-16T14:35:40Z Gge002 52 wikitext 2727 2726 2018-11-16T14:47:23Z Gge002 52 wikitext 2728 2727 2018-11-16T17:45:58Z Gge002 52 wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. ==List of sealed sources at the IFT== ===Storage 4=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 4 #1 | ²⁴¹Am | 27 | 1 000 | 2006 | 458 y | 60 keV gamma | OI428/Code: AMRB 13788 |- | 2 | Storage 4 #2 | ⁵⁷Co | 100 | 3 700 | 2006 | 272 d | 122 keV gamma | Code: CTR 8252 |- | 3 | Storage 4 #3 | ¹³³Ba | 100 | 3 700 | 2006 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Code: BDR 8252 |- | 4 | Storage 4 #4 | ¹⁵⁵Eu | 100 | 3 700 | 1993 | 4.8 y | 105 keV gamma | |- | 5 | Storage 4 #5 | ²²⁶Ra | 2.7 | 100 | ~1970 | 1 600 y | 186 keV gamma | |- | 6 | Storage 4 #6 | ¹³⁷Cs | 60 | 2 200 | 1986 | 30 y | 662 keV gamma | |- | 7 | Storage 4 #7 | ²⁴¹Am | 3 000 | 100 000 | 1977 | 458 y | 60 keV gamma | UB/FIB 539 |- | 8 | Storage 4 #8 | ²⁴¹Am | 10 000 | 370 000 | 1987 | 458 y | | Variable X-ray source |- | 9 | Storage 4 #9 | ⁵⁵Fe | 20 000 | 740 000 | N/A | 2.7 y | X-rays | Decayed |- | 10 | Storage 4 #10 | ¹⁰⁹Cd | 1 | 37 | 2011 | 427 d | 88 keV gamma | Calibr. Set Spectrum Techniques |- | 11 | Storage 4 #11 | ⁵⁷Co | 1 | 37 | 2011 | 272 d | 122 keV gamma | Calibr. Set Spectrum Techniques |- | 12 | Storage 4 #12 | ¹³³Ba | 1 | 37 | 2011 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. Set Spectrum Techniques |- | 13 | Storage 4 #13 | ⁶⁰Co | 1 | 37 | 2011 | 5.3 y | 1 173, 1 333 keV gamma | Calibr. Set Spectrum Techniques |- | 14 | Storage 4 #14 | ¹³⁷Cs | 1 | 37 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 15 | Storage 4 #15 | ²²Na | 1 | 37 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 16 | Storage 4 #16 | ¹³⁷Cs⁶⁵Zn | 1 | 37 | 2011 | 30 y + 244 d | 662 + 1 116 keV gamma | Calibr. Set Spectrum Techniques |- | 17 | Storage 4 #17 | ⁵⁴Mn | 1 | 37 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 18 | Storage 4 #18 | ¹³⁷Cs | 10 | 370 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 19 | Storage 4 #19 | ²²Na | 10 | 370 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 20 | Storage 4 #20 | ⁵⁴Mn | 10 | 370 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 21 | Storage 4 #21 | ¹³³Ba | 10 | 370 | 2012 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. source Eckert & Ziegler |- | 22 | Storage 4 #22 | ²⁴¹Am | 1 | 37 | 1990 | 458 y | 60 keV gamma | Laborel box (ruined and sagregated for disposal) |- | 23 | Storage 4 #23 | ¹⁰⁹Cd | 1 | 37 | 1990 | 427 d | 88 keV gamma | Laborel box |- | 24 | Storage 4 #24 | ¹³⁹Ce | 1 | 37 | 1990 | 138 d | 166 keV gamma | Laborel box |- | 25 | Storage 4 #25 | ⁵⁷Co | 1 | 37 | 1990 | 272 d | 122 keV gamma | Laborel box |- | 26 | Storage 4 #26 | ¹³⁷Cs | 1 | 37 | 1190 | 30 y | 662 keV gamma | Laborel box |- | 27 | Storage 4 #27 | ⁵¹Cr | 1 | 37 | 1990 | 27 d | 320 keV gamma | Laborel box |- | 28 | Storage 4 #28 | ⁵⁴Mn | 1 | 37 | 1990 | 312 d | 835 keV gamma | Laborel box |- | 29 | Storage 4 #29 | ¹¹³Sn | 1 | 37 | 1990 | 115 d | 255 keV gamma | Laborel box |- | 30 | Storage 4 #30 | ⁸⁵Sr | 1 | 37 | 1990 | 65 d | 355 keV gamma | Laborel box |- | 31 | Storage 4 #31 | ⁶⁵Zn | 1 | 37 | 1990 | 244 d | 1 116 keV gamma | Laborel box |- | 32 | Storage 4 #32 | ¹³³Ba | 4 000 | 148 000 | 2014 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Eckert & Ziegler, Brass holder |- | 33 | Storage 4 #33 | ⁹⁰Sr | 54 | 2 010 | 1993 | 29 y | e^- | DESY |- | 34 | Storage 4 #34 | ⁵⁵Fe | 1 000 | 37 000 | 2014 | 2.7 y | X-rays | UiB# 0218698 |- | 35 | Storage 4 #35a | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- | 36 | Storage 4 #35b | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- |} ===Storage 3=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 3 #1 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 2 | Storage 3 #2 | ¹³³Ba | 1 | 37 | 2013 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | |- | 3 | Storage 3 #3 | ²²Na | 1 | 37 | 2013 | 2.6 y | 511, 1 275 keV gamma | |- | 4 | Storage 3 #4 | ⁵⁷Co | 1 | 37 | 2013 | 272 d | 122 keV gamma | |- | 5 | Storage 3 #5a | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 6 | Storage 3 #5b | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 7 | Storage 3 #6 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 3 #7 | ²⁴¹Am | 1 | 37 | 1976 | 458 y | Alpha + 60 keV gamma | Glass tube set |- | 9 | Storage 3 #8 | ⁹⁰Sr | 1 | 37 | 1976 | 29 y | e^- | Glass tube set |- | 10 | Storage 3 #9 | ⁵⁵Fe | 10 | 370 | 1976 | 30 y | 662 keV gamma | Glass tube set |- | 11 | Storage 3 #10 | ¹⁰⁶Ru | 2.7 | 100 | 2000 | 374 d | e^- | |- | 12 | Storage 3 #11 | ²⁴¹Am | 10 | 370 | 1975 | 458 y | Alpha + 60 keV gamma | ORTEC AM-1U, S/N M-1343, act. 0.088 |- |} ===Storage 2=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 2 #1a | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 2 | Storage 2 #1b | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 3 | Storage 2 #1c | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 4 | Storage 2 #1d | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 5 | Storage 2 #1e | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 6 | Storage 2 #1f | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 7 | Storage 2 #2 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 2 #3a | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 9 | Storage 2 #3b | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 10 | Storage 2 #4a | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 11 | Storage 2 #4b | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 12 | Storage 2 #5a | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 13 | Storage 2 #5b | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 14 | Storage 2 #6 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 15 | Storage 2 #7 | ¹⁵²Eu | 0.04 | 1.5 | 2006 | 13.5 y | Many gamma lines | Sealed Liquid |- | 16 | Storage 2 #8a | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 17 | Storage 2 #8b | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 18 | Storage 2 #8c | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 19 | Storage 2 #9a | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 20 | Storage 2 #9b | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 21 | Storage 2 #9c | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 22 | Storage 2 #9d | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 23 | Storage 2 #10 | ¹⁵²Eu | 1 | 37 | 2005 | 13.5 y | Many gamma lines | |- | 24 | Storage 2 #11a | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 25 | Storage 2 #11b | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 26 | Storage 2 #11c | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 27 | Storage 2 #11d | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 28 | Storage 2 #12a | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 29 | Storage 2 #12b | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 30 | Storage 2 #12c | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 31 | Storage 2 #13 | ²⁴¹Am | 0.24 | 9 | N/A | 458 y | 60 keV gamma | GDM 625 |- | 32 | Storage 2 #14 | ¹³⁷Cs | 1.22 | 45 | N/A | 30 y | 662 keV gamma | GDM 134 |- | 33 | Storage 2 #15 | UO₂ | N/A | N/A | N/A | N/A | N/A | Nuclear fuel pellet (black cylinder in epoxy cube) |- |} ===Storage 1=== ====White==== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 1W #1 | ²⁴¹Am | 10 000 | 370 000 | | 458 y | X-rays | Variable X-ray source |- | 2 | Storage 1W #2 | ²⁴¹Am | 10 | 370 | 1993 | 458 y | 60 keV gamma | DA289 written on the source |- | 3 | Storage 1W #3 | ⁶⁰Co | 10 | 370 | 1970 | 10.5 y | 1 173, 1 333 keV gamma | A943F |- | 4 | Storage 1W #4 | ¹⁴⁷Pm | 10 000 | 370 000 | 1974 | 2.6 y | 76, 198 keV gamma | A1124/N11958 |- | 5 | Storage 1W #5 | ¹³⁷Cs | 10 | 370 | | 30 y | 662 keV gamma | S/N 15319; A919F |- | 6 | Storage 1W #6 | ⁶⁰Co | 1 | 37 | | 10.5 y | 1 173, 1 333 keV gamma | S/N 811-L-1 |- | 7 | Storage 1W #7 | ²⁴¹Am | 0.1 | 3.7 | 1966 | 458 y | 60 keV gamma | A922F; S/N M954 Ortec |- | 8 | Storage 1W #8 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 9 | Storage 1W #9 | ¹³⁷Cs | 100 | 3 700 | 1984 | 30 y | 662 keV gamma | |- | 10 | Storage 1W #10 | ²⁴¹Am | 14 000 | 518 000 | 1984 | 458 y | 60 keV gamma | M55005 |- | 11 | Storage 1W #11 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 12 | Storage 1W #12 | ²²⁶Ra | 5-10 | 185-370 | 1970 | 1 600 y | 186 keV gamma | A859F; Leybold in a jar |- | 13 | Storage 1W #13 | ¹³⁷Cs | <10 | <370 | 2005 | 30 y | 662 keV gamma | Isotope generator |- | 14 | Storage 1W #14a | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 15 | Storage 1W #14b | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 16 | Storage 1W #14c | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 17 | Storage 1W #15 | ⁹⁰Sr | 2 000 | 74 000 | 1987 | 29 y | e^- | Amersham (in a square Pb collimator) |- | 18 | Storage 1W #16 | | | | 1945 | | | Hiroshima dust |- | 19 | | | 0 | 0 | 2005 | | | Eluting solution for Tilf #13 Isotope generator |- |} ====Black==== {| class="wikitable" |- ! Item ! Source ID ! Activity, counts/s* ! Note |- | 1 | Storage 1B #1 | ~20 | Storage 1B R. 1 |- | 2 | Storage 1B #2 | ~120 | Storage 1B G. 1 |- | 3 | Storage 1B #3 | ~60 | Storage 1B G. 2 |- | 4 | Storage 1B #4 | ~100 | Storage 1B G. 3 |- | 5 | Storage 1B #5 | ~10 | Storage 1B G. 4 |- | 6 | Storage 1B #6 | ~10 | Storage 1B G. 5 |- | 7 | Storage 1B #7 | ~0 | Storage 1B G. 6 |- | 8 | Storage 1B #8 | ~220 | Storage 1B G. 7 |- | 9 | Storage 1B #9 | ~150 | Storage 1B G. 8 |- | 10 | Storage 1B #10 | ~10 | Storage 1B G. 9 |- | 11 | Storage 1B #11 | ~350 | Storage 1B G. 10 |- | 12 | Storage 1B #12 | ~500 | Storage 1B G. 11 |- | 13 | Storage 1B #13 | ~1 000 | Storage 1B G. 12 |- |} <nowiki>*</nowiki>Activity measured with an 1" NaI(Tl) crystal 94ca13c008cf58a08f251bb3514b34740d696bcd 0 33 2729 2674 2019-01-23T13:06:13Z Nfyku 4 Oppdatert til bitvis UVVM wikitext text/x-wiki <!-- Mapping av alterabibliotek: <pre> vmap cyclonev /prog/altera/vhdl_libs/cyclonev vmap lpm /prog/altera/vhdl_libs/lpm vmap altera /prog/altera/vhdl_libs/altera vmap altera_mf /prog/altera/vhdl_libs/altera_mf </pre> --> [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] [[Synthese av VHDL - Oppdatert]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] <!-- [http://www.ashenden.com.au/ Ashenden Designs] dead link --> [http://freerangefactory.org/books_tuts.html Free Range VHDL textbook] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] <!-- [http://www.ashenden.com.au/designers-guide/VHDL-quick-start.pdf VHDL Quick Start (slides by Ashenden)] dead link --> [http://www.ioenotes.edu.np/media/notes/embedded-system/vhdl.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [https://bitvis.no/dev-tools/uvvm/ Bitvis Universal VHDL Verification Methodology ] [[Category:Mikroelektronikk]] 3c776b44adb85837b7a3ad015a273472ce47102b 2 629 2730 2574 2019-03-02T16:52:10Z Yag005 96 Updated information and added link to thesis wikitext text/x-wiki yag005 is the username for Mats F. Heigre. Mats was part of the microelectronics group in the period August 2016 until he delivered his master thesis and thus finishing his degree in October 2018. His master thesis, Design of an Embedded Readout System for the ALOFT Gamma-Ray Detector Instrument, can be found at BORA under the following link: [http://bora.uib.no/handle/1956/18671 http://bora.uib.no/handle/1956/18671] Contact email: yag005@student.uib.no 1230d4d6cd2f09765d279c0d64ab75b52ff1736b 0 472 2731 2548 2019-11-04T09:01:07Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to server (mikroserver2 or mikroserver3): ssh -X mikroserver2 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2018-19/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] 6c425482017399fb40cacfd7eeabd2121b2f5bef 2732 2731 2019-11-04T09:01:36Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to server (mikroserver1 or mikroserver3): ssh -X mikroserver1 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2018-19/scripts/analog_flow.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] 68c8d3208a0b5e4b9e76bd76ea1f954280a35399 2733 2732 2019-11-04T10:18:08Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to server (mikroserver1 or mikroserver3): ssh -X mikroserver1 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_616_rev1.5.0_a/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2018-19/scripts/analog.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] c5cc3cf3e715b3cd3e01ea16e444b601ac69df34 2747 2733 2020-03-30T08:10:28Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver: ssh -X mikroserver4 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_617_rev1.10.1/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2018-19/scripts/analog.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] 71a9591af333e6d37a9eec50ebaf5ef3d130fdfd 2768 2747 2020-10-15T07:58:27Z Nfyku 4 Updated to new software distro and design kit wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver: ssh -X mikroserver4 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2019-20/scripts/analog.sh cd ~/ihp/cds/ source sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] b5a65fbb463ad05cc17255def87f2f01912b84fd 2770 2768 2020-10-15T08:32:12Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver: ssh -X mikroserver4 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2019-20/scripts/analog.sh cd ~/ihp/cds/ source /eda/design_kits/ihp_sg13/sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] b5a3244736b8a100430eab0e24731421997bbf8a 0 614 2734 2696 2019-11-04T14:51:14Z Nfyku 4 wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''''' The three mikroservers are : * mikroserver1.klientdrift.uib.no * mikroserver2.klientdrift.uib.no * mikroserver3.klientdrift.uib.no == SSH key == * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3.klientdrift.uib.no == Connection aliases == For ease of use set up aliases for the connections in your terminal. Open .bashrc in a text editor (vim / nano) and type in this alias mikroserver1='ssh -X USERNAME@mikroserver1.klientdrift.uib.no' alias mikroserver2='ssh -X USERNAME@mikroserver2.klientdrift.uib.no' alias mikroserver3='ssh -X USERNAME@mikroserver3.klientdrift.uib.no' Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3.klientdrift.uib.no'" >> ~/.bashrc == Automatic sourcing == Source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2018-19/scripts/analog.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc == Commands to run virtuoso remotely == Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3.klientdrift.uib.no 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3.ift.uib.no/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/fredrik/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to * this will copy the file to your home folder on any UiB machine * To copy a folder scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "fli091" [[Category:Mikroelektronikk]] 7a44e6c46dcf48c6dff33ae123f41a76bb6e638a 2746 2734 2020-03-30T07:54:47Z Nfyku 4 Removed full path references wikitext text/x-wiki = Set-up of connection to mikroservers and cadence virtuoso = This set-up will allow you to connect to the mikroservers and/or start Cadence virtuoso with one command without typing any password or host-names. '''NB: This setup is for TSMC, but the commands can be tweaked to be used with IHP or AMS too.''' There are 4 mikroservers, mikroserver1-mikroserver4 == SSH key == * Generate an ssh-key ssh-keygen -f ~/.ssh/id.rsa -t rsa -N '' * Copy the key with your identity to your chosen mikroserver (mikroserver3 is chosen in this example). NB: Replace USERNAME with your user name ssh-copy-id USERNAME@mikroserver3 == Connection aliases == For ease of use set up aliases for the connections in your terminal. Open .bashrc in a text editor (vim / nano) and type in this alias mikroserver1='ssh -X USERNAME@mikroserver1' alias mikroserver2='ssh -X USERNAME@mikroserver2' alias mikroserver3='ssh -X USERNAME@mikroserver3' Also create another alias for your favourite mikroserver echo "alias mikroserver='ssh -X USERNAME@mikroserver3'" >> ~/.bashrc == Automatic sourcing == Source scripts inside .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually # TSMC setup echo "source /eda/cadence/2018-19/scripts/analog.sh" >> ~/.bashrc echo "source /eda/cadence/eda_general_init.sh" >> ~/.bashrc # IHP setup echo "source ~/ihp/cds/sh.cadence" >> ~/.bashrc == Commands to run virtuoso remotely == Then finally on the computers in the lab (NOT connected to the mikroservers) echo "alias virtuoso_tsmc="ssh -X USERNAME@mikroserver3 'cd tsmc;virtuoso &'"" >> ~/.bashrc echo "alias virtuoso_ihp="ssh -X USERNAME@mikroserver3 'cd ihp/cds;virtuoso &'"" >> ~/.bashrc The next time you open your terminal on your computer you can type virtuoso_tsmc to start Cadence Virtuoso, or mikroserver to connect to mikroserver3 without any hassle! == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/USERNAME/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to * this will copy the file to your home folder on any UiB machine * To copy a folder scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to == Troubleshooting == * Make sure you copy your ID (ssh-copy-id) to the correct mikroserver * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB VPN or run the commands via the computers in the lab to be able to connect to microserver * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "abc0123" [[Category:Mikroelektronikk]] e05a6f5755c6a0b739e2312241d116610753f9b0 2754 2746 2020-05-02T14:24:57Z Bhu006 102 Fjernet oppsett av Cadence fra artikkelen siden det dekkes av andre artikler (og stoffet var utdatert). Ryddet opp generelt. wikitext text/x-wiki = Setup of connection to mikroservers= This setup process will allow you to connect to the mikroservers with one command without typing any password or host-names. There are 4 mikroservers at IFT, mikroserver1 through mikroserver4. == SSH key == To login to the server without having to type in your password every time, we can use SSH key pairs. The public key is stored on the server, and you have your private key stored on the UiB login server. To generate a key, type into the terminal ssh-keygen This will generate the files id_rsa and id_rsa.pub in the folder ~/.ssh, where the latter is the public key that needs to be stored on the server. Copy the key with your identity to either mikroserver (mikroserver3 is chosen in this example, but since the user environment is shared for each server, this will give you access to all the servers). You can do this manually, but the easiest way is to use the ssh-copy-id utility. NB: Replace USERNAME with your username ssh-copy-id USERNAME@mikroserver3.ift.uib.no You will be prompted your password. After the key is copied, you should be able to login with "ssh USERNAME@mikroserver3.ift.uib.no" without having to enter your password. == Connection aliases == Now that you can login without typing your password, it is also convenient to set up host names for the servers to connect quicker. To do this, type "gedit ~/.ssh/config" in the terminal. This will open up an empty file, and here you can store short names and specific SSH settings for the connection, such as your username. Host mikroserver3 HostName mikroserver3.ift.uib.no User USERNAME Port 22 ForwardX11 yes ForwardX11Trusted yes Copy and repeat this for each server in the same file, remembering to change the hostname to the corresponding mikroserver for each entry. ForwardX11 allows you to launch software on the server itself, while displaying the GUI remotely to the lab PC. After saving the file, you should be able to simply write "ssh mikroserver3" in the terminal to login to mikroserver3. Note: If you are attempting to do this step remotely from the UiB login server you need to use a terminal-based editor like Vim, or connect to the login-server with ssh -Y USERNAME@login.uib.no to enable the use of graphical editors such as gedit. == Automatic sourcing == There are two main files of sourcing scripts in a Linux environment. One is the file .bashrc, and the other is the file .profile. The difference in these is that the contents of .profile is executed upon login, and .bashrc is executed every time you access the terminal. .bashrc is not sourced to the system by itself upon login, so we need to source .bashrc in .profile manually to use it. This must be done after connecting to one of the mikroservers. echo "source ~/.bashrc" >> ~./profile Scripts can be sourced either within .profile or .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually every time. == Accessing the lab software remotely on your private PC == You do not need to set up a VPN to access the lab software from home. By connecting to the mikroservers through the UiB loginserver with X11 forwarding enabled, you can run the software from any network. You can do this directly on Linux/macOS by using SSH in the bash terminal. For Windows, you will need to download the TTY software [https://www.putty.org/ PuTTY] to enable X11 forwarding. === Linux/macOS === The process is the same for both Linux and macOS, except that for macOS you first have to install the X11 server software named XQuartz. Then, simply connect to the login server by typing ssh -Y USERNAME@login.uib.no The -Y enables trusted X11 forwarding. From here, you can "ssh mikroserver3" just as you would from the lab PC and run software. The steps described above (SSH keys and config files) can be repeated on your personal Linux/macOS PC to simplify connecting to the UiB loginserver. On Linux, the configuration file is located in "~/.ssh/config" just as on the server, while on macOS it is located in "/private/etc/ssh/ssh_config". === Windows === == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/USERNAME/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to * this will copy the file to your home folder on any UiB machine * To copy a folder scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to == Troubleshooting == * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB loginserver or run the commands via the computers in the lab to be able to connect to the mikroservers * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "abc0123" [[Category:Mikroelektronikk]] e9c9f017e806d321dd5205519b4fed5b7ce0b810 2756 2754 2020-05-02T14:30:17Z Bhu006 102 wikitext text/x-wiki = Setup of connection to mikroservers= This setup process will allow you to connect to the mikroservers with one command without typing any password or host-names. There are 4 mikroservers at IFT, mikroserver1 through mikroserver4. == SSH key == To login to the server without having to type in your password every time, we can use SSH key pairs. The public key is stored on the server, and you have your private key stored on the UiB login server. To generate a key, type into the terminal ssh-keygen This will generate the files id_rsa and id_rsa.pub in the folder ~/.ssh, where the latter is the public key that needs to be stored on the server. Copy the key with your identity to either mikroserver (mikroserver3 is chosen in this example, but since the user environment is shared for each server, this will give you access to all the servers). You can do this manually, but the easiest way is to use the ssh-copy-id utility. NB: Replace USERNAME with your username ssh-copy-id USERNAME@mikroserver3.ift.uib.no You will be prompted your password. After the key is copied, you should be able to login with "ssh USERNAME@mikroserver3.ift.uib.no" without having to enter your password. == Connection aliases == Now that you can login without typing your password, it is also convenient to set up host names for the servers to connect quicker. To do this, type "gedit ~/.ssh/config" in the terminal. This will open up an empty file, and here you can store short names and specific SSH settings for the connection, such as your username. Host mikroserver3 HostName mikroserver3.ift.uib.no User USERNAME Port 22 ForwardX11 yes ForwardX11Trusted yes Copy and repeat this for each server in the same file, remembering to change the hostname to the corresponding mikroserver for each entry. ForwardX11 allows you to launch software on the server itself, while displaying the GUI remotely to the lab PC. After saving the file, you should be able to simply write "ssh mikroserver3" in the terminal to login to mikroserver3. Note: If you are attempting to do this step remotely from the UiB login server you need to use a terminal-based editor like Vim, or connect to the login-server with ssh -Y USERNAME@login.uib.no to enable the use of graphical editors such as gedit. == Automatic sourcing == There are two main files of sourcing scripts in a Linux environment. One is the file .bashrc, and the other is the file .profile. The difference in these is that the contents of .profile is executed upon login, and .bashrc is executed every time you access the terminal. .bashrc is not sourced to the system by itself upon login, so we need to source .bashrc in .profile manually to use it. This must be done after connecting to one of the mikroservers. echo "source ~/.bashrc" >> ~/.profile Scripts can be sourced either within .profile or .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually every time. == Accessing the lab software remotely on your private PC == You do not need to set up a VPN to access the lab software from home. By connecting to the mikroservers through the UiB loginserver with X11 forwarding enabled, you can run the software from any network. You can do this directly on Linux/macOS by using SSH in the bash terminal. For Windows, you will need to download the TTY software [https://www.putty.org/ PuTTY] to enable X11 forwarding. === Linux/macOS === The process is the same for both Linux and macOS, except that for macOS you first have to install the X11 server software named XQuartz. Then, simply connect to the login server by typing ssh -Y USERNAME@login.uib.no The -Y enables trusted X11 forwarding. From here, you can "ssh mikroserver3" just as you would from the lab PC and run software. The steps described above (SSH keys and config files) can be repeated on your personal Linux/macOS PC to simplify connecting to the UiB loginserver. On Linux, the configuration file is located in "~/.ssh/config" just as on the server, while on macOS it is located in "/private/etc/ssh/ssh_config". === Windows === == Add mikroserver as a folder on your pc == Open up your home folder in linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/USERNAME/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to * this will copy the file to your home folder on any UiB machine * To copy a folder scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to == Troubleshooting == * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB loginserver or run the commands via the computers in the lab to be able to connect to the mikroservers * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "abc0123" [[Category:Mikroelektronikk]] 3f09b18943be632585aa0ce4596da4998ef79f55 2759 2756 2020-05-03T12:44:05Z Bhu006 102 Included Windows X11 forwarding wikitext text/x-wiki = Setup of connection to mikroservers= This setup process will allow you to connect to the mikroservers with one command without typing any password or long host names. There are 4 mikroservers at IFT, mikroserver1 through mikroserver4. == SSH key == To login to the server without having to type in your password every time, we can use SSH key pairs. The public key is stored on the server, and you have your private key stored on the UiB login server. To generate a key, type into the terminal ssh-keygen This will generate the files id_rsa and id_rsa.pub in the folder ~/.ssh, where the latter is the public key that needs to be stored on the server. Copy the key with your identity to either mikroserver (mikroserver3 is chosen in this example, but since the user environment is shared for each server, this will give you access to all the servers). You can do this manually, but the easiest way is to use the ssh-copy-id utility. NB: Replace USERNAME with your username ssh-copy-id USERNAME@mikroserver3.ift.uib.no You will be prompted your password. After the key is copied, you should be able to login with "ssh USERNAME@mikroserver3.ift.uib.no" without having to enter your password. == Connection aliases == Now that you can login without typing your password, it is also convenient to set up aliases for the servers to connect quicker. To do this, type "gedit ~/.ssh/config" in the terminal. This will open up an empty file, and here you can store shorthand names and specific SSH settings for the connection, such as your username. Host mikroserver3 HostName mikroserver3.ift.uib.no User USERNAME Port 22 ForwardX11 yes ForwardX11Trusted yes Copy and repeat this for each server in the same file, remembering to change the hostname to the corresponding mikroserver for each entry. ForwardX11 allows you to launch software on the server itself, while displaying the GUI remotely to the lab PC. After saving the file, you should be able to simply write "ssh mikroserver3" in the terminal to login to mikroserver3. Note: If you are attempting to do this step remotely from the UiB login server you need to use a terminal-based editor like Vim, or connect to the login-server with ssh -Y USERNAME@login.uib.no to enable the use of graphical editors such as gedit. == Automatic sourcing == There are two main files of sourcing scripts in a Linux environment. One is the file .bashrc, and the other is the file .profile. The difference in these is that the contents of .profile is executed upon login, and .bashrc is executed every time you access the terminal. .bashrc is not sourced to the system by itself upon login, so we need to source .bashrc in .profile manually to use it. This must be done after connecting to one of the mikroservers. echo "source ~/.bashrc" >> ~/.profile Scripts can be sourced either within .profile or .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually every time. == Accessing the lab software remotely on your private PC == You do not need to set up a VPN to access the lab software from home. By connecting to the mikroservers through the UiB loginserver with X11 forwarding enabled, you can run the software from any network. You can do this directly on Linux/macOS by using SSH in the bash terminal. For Windows, you will need to download the X server software [https://sourceforge.net/projects/xming/ Xming] to enable X11 forwarding. This install comes with PuTTY, an SSH client we will use to connect to the Linux based UiB server. === Linux/macOS === The process is the same for both Linux and macOS, except that for macOS you first have to install the X11 server software named [https://www.xquartz.org/ XQuartz]. Then, simply connect to the login server by typing ssh -Y USERNAME@login.uib.no The -Y enables trusted X11 forwarding. From here, you can "ssh mikroserver3" just as you would from the lab PC and run software. The steps described above (SSH keys and config files) can be repeated on your personal Linux/macOS PC to simplify connecting to the UiB loginserver. On Linux, the configuration file is located in "~/.ssh/config" just as on the server, while on macOS it is located in "/private/etc/ssh/ssh_config". === Windows === Install Xming and make sure you include PuTTY in the install. Run Xming. It will start minimized, and does not require any setup. When first opening PuTTY, you will be presented with this configuration menu. Fill in the hostname "login.uib.no", but don't connect yet. [[File:Puttylogin.png]] Navigate to Connection -> SSH -> X11, and check Enable X11 forwarding, and type in "localhost:0.0" as X display location. [[File:Puttyx11.png]] Return to Session, and make sure connection type is set to SSH. Press "Default Settings" and Save to save this configuration for later. Press Open to connect to the server. Enter your username and password, and now you should be in the Linux terminal for the UiB login server. Try to run "gedit" to confirm that you can run a graphical interface. From here you can ssh to the mikroservers and launch software as on the lab computer. Confirm by running gedit on the mikroserver as well to see that you can tunnel X11 through the login server correctly. == Add mikroserver as a folder on your pc == Open up your home folder in Linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: sftp://mikroserver3/home/USERNAME to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver3"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver (ssh mikroserver3) * locate the file you want to copy. i.e /home/USERNAME/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to * this will copy the file to your home folder on any UiB machine * To copy a folder scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to == Troubleshooting == * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB loginserver or run the commands via the computers in the lab to be able to connect to the mikroservers * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "abc0123" [[Category:Mikroelektronikk]] 627cb714f9c299c5a721b44c25be166af25d050f 0 34 2735 2398 2020-01-30T13:57:52Z Nfyku 4 /* Signaler og variable */ wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. ssh -X mikroserver3 # eller mikroserver2 source /eda/mentor/2016-17/scripts/QUESTA-CORE-PRIME_10.5c-4_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet: vsim -voptargs=+acc sign_var Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid? <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (CLK : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference p_test: process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process p_test; END architecture difference; </pre> 13b59f64718c217751e10f4a2de65937dc002c87 2736 2735 2020-01-30T13:59:14Z Nfyku 4 /* Signaler og variable */ wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. ssh -X mikroserver3 # eller mikroserver2 source /eda/mentor/2016-17/scripts/QUESTA-CORE-PRIME_10.5c-4_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet: vsim -voptargs=+acc sign_var Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid? <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (clk : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference p_test: process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process p_test; end architecture difference; </pre> 16b95958fe9e1eb2365af820ea623121762fc71d 2740 2736 2020-01-31T12:51:32Z Nfyku 4 /* Starte Questa Sim */ wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. ssh -X mikroserver3 # eller mikroserver2 source /eda/mentor/2018-19/scripts/QUESTA-CORE-PRIME_10.7c_RHELx86_64.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet: vsim -voptargs=+acc sign_var Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid? <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (clk : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference p_test: process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process p_test; end architecture difference; </pre> 39b0c1ac880de4fbb9e9cc4edf2f76e586d59ddc 2 674 2737 2020-01-30T15:02:04Z Bhu006 102 Created blank page wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 36 2738 2095 2020-01-30T15:13:38Z Bhu006 102 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte synteseprogrammet: source /eda/mentor/2018-19/scripts/PRECISION_2018.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone V med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: vmap cyclonev /prog/altera/vhdl_libs/cyclonev Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 6ed0c4f272130fdfd03f62304fb4390c1030f08a 2739 2738 2020-01-30T15:19:41Z Nfyku 4 /* Modelsim */ wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Pass på at lisensen for Quartus er korrekt satt opp, og at Precision finner Quartus. Precision bruker Quartus til å syntetisere vhdl-koden. For å starte synteseprogrammet: source /eda/mentor/2018-19/scripts/PRECISION_2018.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file(i dette tilfelle alu_example.vhdl). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Cyclone V med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(alu_example.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: vmap cyclonev /eda/altera/17.0/quartus/eda/sim_lib Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til alu_example.vhdl=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT (clk, rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector (3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in: std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF (clk'EVENT AND clk = '1') THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= "0000"; WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF (clk'EVENT AND clk = '1') THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm; </pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 4afa8169a453009b4f3a83c51f5577eaf27ecd42 0 35 2741 2507 2020-01-31T12:53:24Z Nfyku 4 /* Do-file og testbenk */ wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> ssh -X mikroserver3 source /eda/mentor/2018-19/scripts/QUESTA-CORE-PRIME_10.7c_RHELx86_64.sh </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim -voptargs=+acc SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscillasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen. ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. [[Category:VHDL]] [[Category:Mikroelektronikk]] 09c25143639b45c68f6592d670c6c4d600901d78 2742 2741 2020-01-31T12:54:01Z Nfyku 4 /* Do-file og testbenk */ wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : <pre> ssh -X mikroserver3 source /eda/mentor/2018-19/scripts/QUESTA-CORE-PRIME_10.7c_RHELx86_64.sh vsim </pre> ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim -voptargs=+acc SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscillasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen. ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. [[Category:VHDL]] [[Category:Mikroelektronikk]] 36a2fdecc24eece4e39f5261c262459d36a68678 0 202 2743 2708 2020-03-02T14:41:37Z Nfyku 4 /* Prosessteknologi */ wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] e843e7686a7eff84c753e7566c061bfbcdaee62b 2744 2743 2020-03-02T14:45:39Z Nfyku 4 /* Prosessteknologi */ wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process] * [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] 8d589ba195f2b5984353e388812d204e2c4da9f8 2762 2744 2020-09-07T13:26:55Z Nfyku 4 /* Prosessteknologi */ wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process] * [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm] * [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] 6293319f314d50b778db4e1f2623a27a1e5b467a 2763 2762 2020-09-07T13:33:13Z Nfyku 4 /* Prosessteknologi */ wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process] * [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm] * [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory] * [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] b2984106216e2df09bfbe2dae780dd04a27f8902 2764 2763 2020-09-07T13:37:04Z Nfyku 4 /* Prosessteknologi */ wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process] * [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm] * [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory] * [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication] * [https://youtu.be/ApWOf6J858Y Integrated circuit scaling to 10 nm and beyond - Mark Bohr, Intel Senior Fellow] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] 597436770f86d41eb7d445d5916da4bf1c3ef693 0 278 2745 2669 2020-03-02T14:54:48Z Nfyku 4 /* Nettressurser */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Using Vivado ==== * [[Install Vivado 2015.4 with free license]] * [[VGA controller VHDL code]] * [[Nexys4_Master.xdc]] * [[Using the VGA controller with block ram generator and clock wizard]] === Gamle øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] d7fdfc1b813df65a21fd0935e113152f6fde68fb 0 283 2748 1128 2020-03-30T08:21:14Z Nfyku 4 wikitext text/x-wiki ==VNC-SSH innlogging== ===Opprette SSH tunnel=== # Start opp SSH Secure Shell # Velg Profiles → Add Profile… gi den et navn f.eks. "mikroserver2 via login" # Velg Profiles → Edit Profiles…, velg mikroserver2 blant profiles i venstre felt. # Velg Tunneling tab # Velg Outgoing tab ## Klikk Add… ## Skriv inn et navn i Display Name feltet, f.eks. mikroserver2 ## Pass på at Type er TCP ## Skriv inn 5900 i feltet Listen Port ## Sjekk at Allow Local Connections Only er krysset av ## Skriv inn mikroserver2 i Destination Host (adressen til maskinen du kjører VNC server på. Bruk fullt navn om nødvendig: host.klientdrift.uib.no) ## Skriv inn summen av 5900 og ditt desktop nummer, eks 5906, i feltet Destination Port ## Klikk OK # Velg Conection tab ## Skriv inn login.uib.no i Host name feltet ## Skriv inn ditt unix-brukernavn i User name feltet ## Port number skal være 22 ## la resten være som det er. ## Klikk OK (ferdig med konfigurasjon) # Velg Profiles -> "mikroserver2 via login" # Tast inn ditt unix-bruker passord # Legg ned / minimize SSH vinduet, det kjører nå SSH tunnellen og må kjøre så lenge du bruke VNC Viewer via SSH. # Når du er ferdig og har avsluttet VNC Viewer, logger du først ut fra serveren med kommandoen logout og så lukker du SSH vinduet. ====Neste gang du skal opprette SSH tunnellen==== # Start SSH Secure Shell # Utfør punktene fra og med punkt 7 over. ===Login til VNC-SSH server=== Start først opp din egen VNC server som forklart i VNC innlogging mot egen server, eller bruk en eksisternde VNC server. Start VNC Viewer og skriv inn localhost (ikke :port) i Server feltet og click OK og tast inn ditt vnc passord. ===Logout fra egen VNC-SSH server=== Bruk samme fremgangsmåte som forklart under Metode 2 → Logout fra egen VNC server i VNC innlogging. ===Problemer?=== Om du får melding om at SSH tunnell ikke kunne opprettes, sjekk om du kjører VNC-server på din pc, den kan skape problemer. [[Category:Mikroelektronikk]] 51ca6ad0642cb07940f17b521a556f797009b2b0 0 546 2751 2701 2020-04-27T09:48:07Z Bhu006 102 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. The user guide "SG13_user_guide.pdf" can be also be found in the folder "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/doc/pdf" on the microserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:SG13 Design Kit User Guide.pdf]] [[File:SG13 Layout rules.pdf]] [[File:Documentation.png|200px]] If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus QRC. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". The run the QRC. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. [[Category:Mikroelektronikk]] afee4592fb51aa38b2a0aa9d19a7c56bab8f4a54 2752 2751 2020-04-29T12:49:38Z Bhu006 102 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. The user guide "SG13_user_guide.pdf" can be also be found in the folder "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/doc/pdf" on the microserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:SG13 Design Kit User Guide.pdf]] [[File:SG13 Layout rules.pdf]] [[File:Documentation.png|200px]] If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. [[Category:Mikroelektronikk]] 715d975acd13e0418cf70518a588d400317508d7 2753 2752 2020-05-01T11:11:03Z Bhu006 102 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. The user guide "SG13_user_guide.pdf" can be also be found in the folder "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/doc/pdf" on the microserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:SG13 Design Kit User Guide.pdf]] [[File:SG13 Layout rules.pdf]] [[File:Documentation.png|200px]] If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] Note that there is a specified minimum enclosure in the design rules for vias between polysilicon and metal. This is because during the manufacturing process, the polysilicon and metal layers are created separately and the alignment is not perfect, so the polysilicon connection must be slightly larger to accommodate the potential offset between these layers. Enclosures can be seen by the polysilicon squares on the vias connecting the Q and Q_B lines in the design above. To set a via enclosure size, right click the via and go to properties. On the bottom, there is a setting for GatPoly enclosure. You must set each direction separately. = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. [[Category:Mikroelektronikk]] e0c86f0482a571d11bbad7b544af56ec277bdd52 2769 2753 2020-10-15T08:07:40Z Nfyku 4 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. The user guide "SG13_user_guide.pdf" can be also be found in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the microserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. [[File:SG13 Design Kit User Guide.pdf]] [[File:SG13 Layout rules.pdf]] [[File:Documentation.png|200px]] If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] Note that there is a specified minimum enclosure in the design rules for vias between polysilicon and metal. This is because during the manufacturing process, the polysilicon and metal layers are created separately and the alignment is not perfect, so the polysilicon connection must be slightly larger to accommodate the potential offset between these layers. Enclosures can be seen by the polysilicon squares on the vias connecting the Q and Q_B lines in the design above. To set a via enclosure size, right click the via and go to properties. On the bottom, there is a setting for GatPoly enclosure. You must set each direction separately. = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. [[Category:Mikroelektronikk]] c02cb9990b3bb657c94e0a1522b82540bcd91ffd 2771 2769 2020-10-15T09:19:12Z Nfyku 4 wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] Note that there is a specified minimum enclosure in the design rules for vias between polysilicon and metal. This is because during the manufacturing process, the polysilicon and metal layers are created separately and the alignment is not perfect, so the polysilicon connection must be slightly larger to accommodate the potential offset between these layers. Enclosures can be seen by the polysilicon squares on the vias connecting the Q and Q_B lines in the design above. To set a via enclosure size, right click the via and go to properties. On the bottom, there is a setting for GatPoly enclosure. You must set each direction separately. = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. [[Category:Mikroelektronikk]] 899f274f6e9da6d84a3b9f2ec11dd262e0edc4c2 0 25 2755 2661 2020-05-02T14:26:50Z Bhu006 102 wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Xilinx === * [[Xilinx Vivado]] Tutorials for Xilinx Vivado * [[Xilinx SDK]] Tutorials for Xilinx Software Development Kit === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[FreeRTOS]] Free Real Time Operating System == Andre fagressurser og laboratorieveiledninger== * [[MikroserverSetup]] Oppsett av enkel tilkobling til mikroserverene * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] 417dc3b359ef9963d4ceab537e8242419b06fc04 2760 2755 2020-08-18T14:07:19Z Nfyku 4 wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Xilinx === * [[Xilinx Vivado]] Tutorials for Xilinx Vivado * [[Xilinx SDK]] Tutorials for Xilinx Software Development Kit === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[FreeRTOS]] Free Real Time Operating System == Andre fagressurser og laboratorieveiledninger== * [[MikroserverSetup]] Oppsett av enkel tilkobling til mikroserverene * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Populærvitenskaplig om elektronikk == * [https://youtu.be/NUUeGianTKM The Story of Electricity - BBC Documentary] == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] 78f49faf7e8a6fbc547ba84bca6c244185e080af 2761 2760 2020-08-18T14:11:34Z Nfyku 4 wikitext text/x-wiki == Øvinger og guider == === Mentor Graphics === * [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB * [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim === Cadence === * [[Cadence Virtuoso]] === Microsemi === * [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus === Xilinx === * [[Xilinx Vivado]] Tutorials for Xilinx Vivado * [[Xilinx SDK]] Tutorials for Xilinx Software Development Kit === Annet === * [[Bitvis UVVM VHDL Verification Component Framework]] * [[Tutorials]] Tutorials from the web * [[XJTAG]]  Boundary Scan with XJTAG * [[XJDeveloper]] Innføring i XJDeveloper * [[FreeRTOS]] Free Real Time Operating System == Andre fagressurser og laboratorieveiledninger== * [[MikroserverSetup]] Oppsett av enkel tilkobling til mikroserverene * [[PHYS222]] Fagressurser for PHYS222 og PHYS223 * [[PHYS321]] Fagressurser for PHYS321 * [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare * [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern) * [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven == Populærvitenskaplig om elektronikk == * [https://youtu.be/NUUeGianTKM The Story of Electricity - BBC Documentary] * [https://www.youtube.com/watch?v=U4XknGqr3Bo Transiztorized! ] == Eldre øvinger og guider == === Mentor Graphics === * [[IC studio]] Veiledning til IC-design ved hjelp av IC studio * [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol * [[IC Station]] Tegne utlegg for integrerte kretser === Annet === * [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort * [[Xilinx]] Øving i bruk av Xilinx Project Studio * [[SmartFusion2]] Oppsett og design med SF2 * [[FLTK GUI]] Graphical User Interface using FLTK [[Category:Mikroelektronikk]] fd928e9ce7c3e52dc2ce84cbeaee7691e345d237 6 677 2757 2020-05-03T12:22:44Z Bhu006 102 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 678 2758 2020-05-03T12:22:52Z Bhu006 102 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 217 2765 2334 2020-09-23T11:02:34Z Nfyku 4 Updated for newer Matalb versions (tested on R2020b) wikitext text/x-wiki === Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin === <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vo as a function of Vin % Only Cgd is considered (Zc) % Kjetil Ullaland syms s C Vin Vo Vgs Zc gm Rl Rs R Av Avo eq1=(Vo-Vgs)/(R+Zc)+gm*Vgs+Vo/Rl == 0; eq2=(Vgs-Vo)/(R+Zc)+(Vgs-Vin)/Rs == 0; eq1=subs(eq1,Zc,1/(s*C)); eq2=subs(eq2,Zc,1/(s*C)); disp('KCL for circuit node 1:'); pretty(eq1); disp('KCL for circuit node 2:'); pretty(eq2); disp('Solve for Vo and Vin and calculate Av (Vo/Vin):'); solved=solve(eq1,eq2,Vo,Vin); Av=solved.Vo/solved.Vin; pretty(simplify(Av)); pretty(subs(Av,Rl*gm,Avo)); </pre> === Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is === <pre> % Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 % to find Vo as a function of Is % Kjetil Ullaland, 2015 syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz; %% With feedforward capacitor eq1=sym('(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/Zc+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=subs(eq1,V1,solV1); SolVo=simplify(solve(eq3,[Vo])); disp('With capacitor only in feedforward loop'); pretty(simplify(SolVo/Is)); %% With series resistor and capacitor in feedforward loop eq1=sym('(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2=0'); eq2=sym('(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is=0'); eq1=subs(eq1,Zc,'1/(s*C)'); eq2=subs(eq2,Zc,'1/(s*C)'); solV1=solve(eq2,V1); eq3=simplify(subs(eq1,V1,solV1)); SolVo=solve(eq3,[Vo]); disp('With series resistor and capacitor in feedforward loop'); pretty(simplify(SolVo/Is)); </pre> 8ce3c9f3b005d733aadb9b03bc1f4ceccd909c4d 2766 2765 2020-09-23T11:13:48Z Nfyku 4 wikitext text/x-wiki === Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin === <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vo as a function of Vin % Only Cgd is considered (Zc) % Kjetil Ullaland syms s C Vin Vo Vgs Zc gm Rl Rs R Av Avo eq1=(Vo-Vgs)/(R+Zc)+gm*Vgs+Vo/Rl == 0; eq2=(Vgs-Vo)/(R+Zc)+(Vgs-Vin)/Rs == 0; eq1=subs(eq1,Zc,1/(s*C)); eq2=subs(eq2,Zc,1/(s*C)); disp('KCL for circuit node 1:'); pretty(eq1); disp('KCL for circuit node 2:'); pretty(eq2); disp('Solve for Vo and Vin and calculate Av (Vo/Vin):'); solved=solve(eq1,eq2,Vo,Vin); Av=solved.Vo/solved.Vin; pretty(simplify(Av)); pretty(subs(Av,Rl*gm,Avo)); </pre> === Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is === <pre> % Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 % to find Vo as a function of Is % Kjetil Ullaland, 2020 syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz; %% With feedforward capacitor eq1=(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2==0; eq2=(V1-Vo)/Zc+V1*s*C1+V1/R1+Is==0; eq1=subs(eq1,Zc,1/(s*C)); eq2=subs(eq2,Zc,1/(s*C)); disp('Solve for Vo and V1 and calculate Vo/Is with capacitor only in feedforward loop'); solved=solve(eq1,eq2,Vo,Is); VoOnIs=solved.Vo/solved.Is; pretty(simplify(VoOnIs)); %% With series resistor and capacitor in feedforward loop eq1=(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2==0; eq2=(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is==0; eq1=subs(eq1,Zc,1/(s*C)); eq2=subs(eq2,Zc,1/(s*C)); disp('Solve for Vo and V1 and calculate Vo/Is with resistor and capacitor in feedforward loop'); solved=solve(eq1,eq2,Vo,Is); VoOnIs=solved.Vo/solved.Is; pretty(simplify(VoOnIs)); </pre> fbb47afba3c460ba26ee4e4fb59257ecd51b73ee 2767 2766 2020-09-23T11:39:47Z Nfyku 4 Added calculation for all capacitors wikitext text/x-wiki === Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin === <pre> % Using Kirchoff's current law (KCL) on a source follower configuration % to find Vo as a function of Vin % Kjetil Ullaland, 2020 syms s Cdg Cgs Cds Vin Vo Vgs Zc gm Rl Rs R Av Avo %% disp('Only Cgd with series resistor is considered (Zc)') eq1=(Vo-Vgs)/(R+Zc)+gm*Vgs+Vo/Rl == 0; eq2=(Vgs-Vo)/(R+Zc)+(Vgs-Vin)/Rs == 0; eq1=subs(eq1,Zc,1/(s*Cdg)); eq2=subs(eq2,Zc,1/(s*Cdg)); disp('KCL for circuit node 1:'); pretty(eq1); disp('KCL for circuit node 2:'); pretty(eq2); disp('Solve for Vo and Vin and calculate Av (Vo/Vin):'); solved=solve(eq1,eq2,Vo,Vin); Av=solved.Vo/solved.Vin; pretty(simplify(Av)); pretty(subs(Av,Rl*gm,Avo)); %% disp('All MOST capasitors are considered') syms s Cdg Cgs Cds Vin Vo Vgs gm Rl Rs Av Avo eq1=(Vo-Vgs)*s*Cdg + gm*Vgs + Vo/Rl + Vo*s*Cds == 0; eq2=(Vgs-Vin)/Rs + Vgs*s*Cgs + (Vgs-Vo)*s*Cdg == 0; disp('KCL for circuit node 1:'); pretty(eq1); disp('KCL for circuit node 2:'); pretty(eq2); disp('Solve for Vo and Vin and calculate Av (Vo/Vin):'); solved=solve(eq1,eq2,Vo,Vin); Av=solved.Vo/solved.Vin; pretty(simplify(Av)); pretty(subs(Av,Rl*gm,Avo)); </pre> === Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is === <pre> % Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 % to find Vo as a function of Is % Kjetil Ullaland, 2020 syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz; %% With feedforward capacitor eq1=(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2==0; eq2=(V1-Vo)/Zc+V1*s*C1+V1/R1+Is==0; eq1=subs(eq1,Zc,1/(s*C)); eq2=subs(eq2,Zc,1/(s*C)); disp('Solve for Vo and V1 and calculate Vo/Is with capacitor only in feedforward loop'); solved=solve(eq1,eq2,Vo,Is); VoOnIs=solved.Vo/solved.Is; pretty(simplify(VoOnIs)); %% With series resistor and capacitor in feedforward loop eq1=(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2==0; eq2=(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is==0; eq1=subs(eq1,Zc,1/(s*C)); eq2=subs(eq2,Zc,1/(s*C)); disp('Solve for Vo and V1 and calculate Vo/Is with resistor and capacitor in feedforward loop'); solved=solve(eq1,eq2,Vo,Is); VoOnIs=solved.Vo/solved.Is; pretty(simplify(VoOnIs)); </pre> 13d444112847817b98634c38e4df375714958f2e 0 472 2772 2770 2020-10-15T09:20:58Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver: ssh -X mikroserver4 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2019-20/scripts/analog.sh cd ~/ihp/cds/ source /eda/design_kits/ihp_sg13/sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] = Before starting layout = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] 0c9e6adccfdb0a73072ff441e31be1745f8dc6f7 2773 2772 2020-10-15T11:30:42Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver: ssh -X mikroserver4 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2019-20/scripts/analog.sh cd ~/ihp/cds/ source /eda/design_kits/ihp_sg13/sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] = Before starting designing = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] d73f2c8f3e95b2785e2e4759eba7fa91ffbef3a3 0 1 2774 2400 2020-11-03T23:28:38Z Nfyal 26 need this wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[DAMARA]] * [[Detector lab]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [http://wiki.uib.no/nanolab Nano Lab] * [[Particle Physics group]] * [[GRIEG project "EarlyUniverse"]] * [[Strålevern]] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 2884e13c9f7bde42673aac188f34fc18efaf82d4 2799 2774 2020-11-25T14:41:40Z Nfyal 26 wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[DAMARA]] * [[Detector lab]] * [[Cerenkov Telescope Array -Norway]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [http://wiki.uib.no/nanolab Nano Lab] * [[Particle Physics group]] * [[GRIEG project "EarlyUniverse"]] * [[Strålevern]] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 4edb618dd513d40126950a0e23ed83fb3cde4e22 0 679 2775 2020-11-03T23:32:04Z Nfyal 26 Created page with "[[Media:grieg-logo.png]]" wikitext text/x-wiki [[Media:grieg-logo.png]] 8163af9ec00b56f910199bead7dfdf08c853f296 2777 2775 2020-11-03T23:34:34Z Nfyal 26 wikitext text/x-wiki [[Media:grieg-logo.png]] [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] b0ab2c78b9814687c087134978f454c044e8ca39 2778 2777 2020-11-03T23:42:42Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [[Image:grieg-logo.png]] [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] Wiki page for "EarlyUniverse project, with participants from Bergen Highe Energy Physics Group, and Particle Theory, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka and she will figure out who can activate your account, === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === 3f7f567967c0050deb85363faad5b9e5a82b3d4a 2780 2778 2020-11-03T23:55:30Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [[Image:grieg-logo.png]] [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] Wiki page for "EarlyUniverse project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka and she will figure out who can activate your account, === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === 7aaf655273d36b06bb9b0964972b27db79a8f592 2781 2780 2020-11-03T23:56:19Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [[Image:grieg-logo.png]] [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka and she will figure out who can activate your account, === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === f84c4fc409f982b9832b426816176ec8e0bda15c 2782 2781 2020-11-04T00:10:39Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] [[Image:grieg-logo.png]] Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === a182d881af73fd5a47485206e835aa65ced6d165 2783 2782 2020-11-04T00:11:45Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] This is Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === [[Image:grieg-logo.png]] 61566e36511693f39dd2c2463b15a734b6713e29 2784 2783 2020-11-10T14:01:43Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] This is Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === Bergen particle physics group twiki: [[https://wiki.uib.no/ift/index.php/Particle_Physics_group Bergen particle physics]] [[Image:grieg-logo.png]] d8bceeafef0db9f1ea64a22401230b445baeb367 2788 2784 2020-11-10T14:11:38Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] This is Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === === [[PublicationsOfInterests| Presentations of Interest]] === Bergen particle physics group twiki: [[https://wiki.uib.no/ift/index.php/Particle_Physics_group Bergen particle physics]] [[Image:grieg-logo.png]] 2317cf161e2a28276760c4195c0dc544ae1ebb9d 2803 2788 2021-02-03T22:28:05Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] The project is financed by Norwegian Financial Mechanism, with the latest possible use of funds in 31 of March 2024. This is Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === === [[PublicationsOfInterests| Presentations of Interest]] === Bergen particle physics group twiki: [[https://wiki.uib.no/ift/index.php/Particle_Physics_group Bergen particle physics]] [[Image:grieg-logo.png]] 4b2c3fbf9fe4b2bd412bc7e8456fe7f40114e3a2 2804 2803 2021-02-03T22:35:24Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] The project is financed by Norwegian Financial Mechanism, with the latest possible use of funds in 31 of March 2024. This is Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. === [[EarlyUniverseProjectShared|Sharing Ideas]] === === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === === [[PublicationsOfInterests| Presentations of Interest]] === Bergen particle physics group twiki: [[https://wiki.uib.no/ift/index.php/Particle_Physics_group Bergen particle physics]] [[Image:grieg-logo.png]] fc65e4ee76fb5f290442da8532537253ba1ee0d5 6 680 2776 2020-11-03T23:32:30Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 681 2779 2020-11-03T23:53:03Z Nfyal 26 Created page with "== Seminar and meeting information == The project meetings and task meetings (tasks 1 to 5) can be found in the following CERN indico category. https://indico.cern.ch/cate..." wikitext text/x-wiki == Seminar and meeting information == The project meetings and task meetings (tasks 1 to 5) can be found in the following CERN indico category. https://indico.cern.ch/category/8493/ They are clearly marked "GRIEG Early Universe" so you should be able to find them out. We have an ongoing zoom meeting: https://uib.zoom.us/j/68546966413?pwd=NXBVTDhiRTJWSkJEYmVDWVNyRUxHQT09 a673e2fe69170207d02d3ea5e09fe8643d210b89 0 139 2785 2544 2020-11-10T14:03:50Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 9:30, on vidyo, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics). This includes 2016-2017 Bergen-Oslo meetings. https://indico.cern.ch/category/7495/ Grieg project meetings, UiB+UW are here: https://wiki.uib.no/ift/index.php/EarlyUniverseProjectMeetings Old and not updated Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here (I still keep it for a while): https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2018 === "Spatind conference", Nordic Bi-annual conference in High Energy Physics, 2-8 January 2018 [https://indico.cern.ch/event/666278/ web page] Please register ASAP. you are (most probably) funded by the HEPP project. * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] e339ab1a6ae6233bf8b37bff706bd341e4708410 0 137 2786 2564 2020-11-10T14:06:48Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report (not the final version alas) from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] a0ff60b4fac1f4ce710fb988531698a310697aee 2787 2786 2020-11-10T14:09:16Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report (not the final version alas) from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== we filled two postdoc positions in 2013, and PhD theory position in 2015, PhD in ATLAS in 2016. We will have more openings coming years. all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 2dc6f3fe8c3eed1f7c3f1caf526ea46648ac1323 0 682 2789 2020-11-10T14:14:00Z Nfyal 26 Created page with "Report from Higgs2020 conference [[Media:higgs2020.pdf]]" wikitext text/x-wiki Report from Higgs2020 conference [[Media:higgs2020.pdf]] a78687ecf831caa6193f869ffa85f496679e99c3 6 683 2790 2020-11-10T14:15:10Z Nfyal 26 summary of higgs2020 conference, Valerio Dao wikitext text/x-wiki summary of higgs2020 conference, Valerio Dao ce5009e93e0b18df61f5eae30f095c8f3bd582fa 4 684 2791 2020-11-10T14:25:43Z Nfyal 26 Created page with "Nfyal" wikitext text/x-wiki Nfyal 0ce11b293ba0de5beefd8c8b566409b20d7700d7 2793 2791 2020-11-10T14:29:25Z Nfyal 26 wikitext text/x-wiki Nfyal Nfyst b802a272f9ff6f611ed6a539bb7daf5f84113d57 2794 2793 2020-11-10T14:31:04Z Nfyal 26 wikitext text/x-wiki [Nfyal] [Nfyst] [] ebb4908607eea3247c58fbabdf605ecb721618c6 2795 2794 2020-11-10T14:31:38Z Nfyal 26 wikitext text/x-wiki [[Nfyal]] [[Nfyst]] [] f8f0e104dd612a9acdc138c6bdba184986b13e4d 2796 2795 2020-11-10T14:32:13Z Nfyal 26 wikitext text/x-wiki [Nfyal] [Nfyst] [] 5ca7c744213a72c022db5338a0c3531996de8f02 2797 2796 2020-11-10T14:33:40Z Nfyal 26 wikitext text/x-wiki [User:Nfyal] [User:Nfyst] [User:Nfo058] 7bcf6263562363732ce69d0c9f4cb1276c8c964f 2798 2797 2020-11-10T14:34:15Z Nfyal 26 wikitext text/x-wiki User:Nfyal User:Nfyst User:Nfo058 61bafb8cd3ee45734438153f17d0f8e9460b3b5f 4 685 2792 2020-11-10T14:26:22Z Nfyal 26 Created page with "Nfyal" wikitext text/x-wiki Nfyal 0ce11b293ba0de5beefd8c8b566409b20d7700d7 0 686 2800 2020-11-25T14:44:58Z Nfyal 26 Created page with "This is Wiki page for Cerenkov Telescope Array-Norway, with participants from Bergen High Energy Physics Group, Astroparticle Physics at NTNU, and Department of Physics at t..." wikitext text/x-wiki This is Wiki page for Cerenkov Telescope Array-Norway, with participants from Bergen High Energy Physics Group, Astroparticle Physics at NTNU, and Department of Physics at the University of Oslo. People: 13a266210580b1a622f6aeffff14ae217f5ab7a5 0 234 2801 2704 2020-12-11T14:14:40Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 803594e4b4c81447838022d30e5beccc21bdc714 6 687 2802 2020-12-11T14:15:12Z Nfyal 26 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 688 2805 2021-02-03T23:01:47Z Nfyal 26 Created page with "We need perhaps to get SLACK exchange, but at the moment we just wanted a googledoc to get common publications ideas. For now there is a googledoc here: https://docs.google.c..." wikitext text/x-wiki We need perhaps to get SLACK exchange, but at the moment we just wanted a googledoc to get common publications ideas. For now there is a googledoc here: https://docs.google.com/document/d/1wI4SBN6AphG6tJvNfGKKb01bpejK--4kzkP9RY4Awfw/ 487f911a44c0e9d7379a53cfebabc41d357d0537 0 36 2806 2739 2021-02-04T12:52:47Z Nfyku 4 Updated to Vivado wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen: setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus ==Modelsim== Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik: vmap cyclonev /eda/altera/17.0/quartus/eda/sim_lib Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksemple på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] b35a0734bd54fe6589c433253c569722bf61e836 2807 2806 2021-02-04T13:37:06Z Nfyku 4 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler. Vi har kompilert disse bibliotekene til mappen /eda/xilinx. Du kan "mappe" disse for eksempel slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] ae1d0f604fc38afd0088b04fb06f2e44d962a369 2808 2807 2021-02-04T13:39:37Z Nfyku 4 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] cf526d48fd1255263f913e079e3db50892b453b9 2809 2808 2021-02-04T13:46:34Z Nfyku 4 /* Precision */ wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 3194fd9453ff5d0a1b262c71b432a1ec28542d46 2810 2809 2021-02-04T13:48:16Z Nfyku 4 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 512ee8e2dfb2ff459c3832a02cdf190c4865c21d 2812 2810 2021-02-04T21:05:20Z Nfyku 4 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] fbcb137707b0a3f46a2edce0d3dfdeddc360d9a0 2817 2812 2021-02-05T08:05:35Z Nfyku 4 /* Precision */ wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk, reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end; </pre> [[Category:Mikroelektronikk]] 2066e6d3c6fdf154f1fa3efd793c6d4516a4c887 2818 2817 2021-02-05T12:10:31Z Nfyku 4 /* Koden til alu_tb.vhdl */ wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk : std_logic; signal reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end architecture struct; </pre> [[Category:Mikroelektronikk]] ea8aaf101a256c12f3be1b2a5dabed22b7439d2d 2819 2818 2021-02-05T13:44:45Z Nfyku 4 oppdatert sdf-inkludering med sdfnoerror wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh precision Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps -sdfnoerror -sdfmax /alu_synth=/home/kaf003/VHDL_Prosjekter/PHYS321/vivado_impl_1/add_sub_alu_synth.sdf work.alu_tb Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk : std_logic; signal reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end architecture struct; </pre> [[Category:Mikroelektronikk]] f3427a132aea2910060b03c6692e967202fb2bad 0 33 2811 2729 2021-02-04T21:02:47Z Nfyku 4 wikitext text/x-wiki [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] <!-- [http://www.ashenden.com.au/ Ashenden Designs] dead link --> [http://freerangefactory.org/books_tuts.html Free Range VHDL textbook] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] [http://www.ioenotes.edu.np/media/notes/embedded-system/vhdl.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [https://bitvis.no/dev-tools/uvvm/ Bitvis Universal VHDL Verification Methodology ] [[Category:Mikroelektronikk]] 9a1780dfc3eae9230116075487948c87a6b569a4 2816 2811 2021-02-04T21:13:27Z Nfyku 4 /* Referanselitteratur */ wikitext text/x-wiki [[Simulering av VHDL]] [[VHDL Testbenk]] [[Synthese av VHDL]] == Referanselitteratur == [http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL] [http://freerangefactory.org/books_tuts.html Free Range VHDL textbook] [http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example] [http://www.ioenotes.edu.np/media/notes/embedded-system/vhdl.pdf VHDL Quick Start (slides by Ashenden)] [http://model.com/content/modelsim-pe-simulation-and-debug Modelsim] [http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL] [http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide] [http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer] [https://bitvis.no/dev-tools/uvvm/ Bitvis Universal VHDL Verification Methodology ] [https://github.com/UVVM Bitvis UVVM på GitHub ] [[Category:Mikroelektronikk]] cde12bb4e6d21cbb3ea8004fca22ff54d561bc63 0 34 2813 2740 2021-02-04T21:06:41Z Nfyku 4 /* Starte Questa Sim */ wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. ssh -X mikroserver4 export LM_LICENSE_FILE=1717@lisensserver source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet: vsim -voptargs=+acc sign_var Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid? <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (clk : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference p_test: process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process p_test; end architecture difference; </pre> fad112a06c06d20a8f6f7baeca7e4ad92434c588 0 35 2814 2742 2021-02-04T21:08:46Z Nfyku 4 wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : ssh -X mikroserver4 source /eda/mentor/2019-20/scripts/QUESTA-CORE-PRIME_2019.4_RHELx86.shvsim ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim -voptargs=+acc SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscillasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen. ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. [[Category:VHDL]] [[Category:Mikroelektronikk]] 5b6985cf1c06d998628533fe860a626960023d1a 2815 2814 2021-02-04T21:09:23Z Nfyku 4 /* Do-file og testbenk */ wikitext text/x-wiki ===Simulering av kode og testbenk i QuestaSim=== ==Do-file og testbenk== Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer. Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering. Oppstart av modelsim Opne eit terminalvindu, og skriv : ssh -X mikroserver4 source /eda/mentor/2019-20/scripts/QUESTA-CORE-PRIME_2019.4_RHELx86.sh vsim ==Lage prosjekt i modelsim== Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer. Koden til SR_latch.vhdl <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ==Bruk av "Do-file"== Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut: <pre> # Starter simulering på nytt (clear) restart -f # Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns force s 1 100 ns, 0 200 ns -repeat 200 ns force r 1 100 ns, 0 300 ns -repeat 400 ns # Simulerer i 800ns run 800 ns </pre> Bruk av do-file <pre> vsim -voptargs=+acc SR_latch add wave * do f.do </pre> Resultat av simulering # ** Error: (vsim-3601) Iteration limit reached at time 500 ns. Som viser at vi får oscillasjon etter 500ns. Vi får også opp eit wave-vindu med alle signal som er beskrive i entity. ==Testbenk i VHDL== No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar. Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår. *Eksempelkode til SR_tb.vhdl:* <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; --Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken. entity sr_tb is end entity sr_tb; architecture struct of sr_tb is --Deklarerer testsignalar og kva type dei er. signal S_tb : std_logic; signal R_tb : std_logic; signal Q_tb : std_logic; signal QB_tb : std_logic; begin --Velg kva einheit testbenken skal teste. SR : entity SR_latch(behave) --Koblar signala fra einheiten til testbenken. port map ( S => S_tb, R => R_tb, Q => Q_tb, QB => QB_tb); --Setter testvektorane, venter og ser kva vi får ut. --Samanliknar med forventa resultat, og gir ut eventuelle error. --Vi har lagt inn alle feiltypane i assert som eit eksempel. process begin --Setter S_tb <= '0'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q vart ikkje 1!" severity Error; assert (QB_tb = '0') report "QB vart ikkje 0!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier for å lage feilmelding assert (Q_tb = '0') report "Dette er ein feil" severity Error; assert (QB_tb = '1') report "Ein feil til" severity warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q vart ikkje 0!" severity Error; assert (QB_tb = '1') report "QB vart ikkje 1!" severity Error; --Ingen endring S_tb <= '1'; R_tb <= '1'; wait for 100 ns; --Tester på feil verdier assert (Q_tb = '1') report "Endå meir feil" severity note; assert (QB_tb = '0') report "hu, masse feil ja" severity Warning; --Reset S_tb <= '1'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '0') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Set og reset S_tb <= '0'; R_tb <= '0'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '1') report "QB does not match the expected value!" severity Error; --Oscillilerer S_tb <= '1'; R_tb <= '1'; wait for 100 ns; assert (Q_tb = '1') report "Q does not match the expected value!" severity Error; assert (QB_tb = '0') report "QB does not match the expected value!" severity Error; end process; end; </pre> For å kjøre igjennom hele filen bruker en run -all ==Resultat== Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere. <pre> # ** Error: Dette er ein feil # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Warning: Ein feil til # Time: 200 ns Iteration: 0 Instance: :sr_tb # ** Note: Endå meir feil # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Warning: hu, masse feil ja # Time: 400 ns Iteration: 0 Instance: :sr_tb # ** Error: (vsim-3601) Iteration limit reached at time 600 ns. </pre> Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen. ==Konklusjon== Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil. [[Category:VHDL]] [[Category:Mikroelektronikk]] 0cda34c218a0ad99a8fc53821f5435938b5e1ae3 0 189 2820 2672 2021-02-22T16:10:41Z Lra034 110 /* XJDeveloper Tutorial */ wikitext text/x-wiki =XJDeveloper Tutorial= You should run the tutorial XJDeveloper tutorial (you can search for the app, or it can be found under XJTAG 3.10 in the windows start meny). The program this tutorial is designed for is called XJDeveloper 3.10. In this tutorial you can choose between version 4.2 and 3.1 of the XJDemo board, we are using version 3.1. The tutorial provides a turtorial.zip file with the files you're going to use. Unzip this to a new folder for your project. Below are pictures of versions 1.2 and 2.0 of the XJDemo board side-by-side so you can identify which you have. The main identifying feature of version 2.0 is its blue thumbwheel. On the 3.1 version you will see the name written on the card. [[Image:XJDemo v3.1.png]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board. Refer to the schematic for the pinmapping for page 11 of the tutorial. # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. =Additional resources= [[XJTAG_for_new_prototypes]] [[Category:Mikroelektronikk]] fcf031cd7f55ca6ca0adcce017b38b80e95e6c07 6 689 2821 2021-02-22T16:11:09Z Lra034 110 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 189 2822 2820 2021-02-22T16:25:52Z Lra034 110 /* XJDeveloper Tutorial */ wikitext text/x-wiki =XJDeveloper Tutorial= You should run the tutorial XJDeveloper tutorial (you can search for the app, or it can be found under XJTAG 3.10 in the windows start meny), the tutorial contains a detailed description on what to do. The program this tutorial is designed for is called XJDeveloper 3.10. In this tutorial you can choose between version 4.2 and 3.1 of the XJDemo board, we are using version 3.1. The tutorial provides a turtorial.zip file with the files you're going to use. Unzip this to a new folder for your project. Below are a pictures of versions 3.1 of the XJDemo board. [[Image:XJDemo v3.1.png]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board. Refer to the schematic for the pinmapping for page 11 of the tutorial. # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. =Additional resources= [[XJTAG_for_new_prototypes]] [[Category:Mikroelektronikk]] 76e9dc1b634430df2b4dbfac1bf7a96421a6dbd0 2823 2822 2021-02-22T16:26:39Z Lra034 110 /* XJDeveloper Tutorial */ wikitext text/x-wiki =XJDeveloper Tutorial= You should run the tutorial XJDeveloper tutorial (you can search for the app, or it can be found under XJTAG 3.10 in the windows start meny), the tutorial contains a detailed description on what to do. The program this tutorial is designed for is called XJDeveloper 3.10. In this tutorial you can choose between version 4.2 and 3.1 of the XJDemo board, we are using version 3.1. The tutorial provides a turtorial3.zip file with the files you're going to use. Unzip this to a new folder for your project. Below are a pictures of versions 3.1 of the XJDemo board. [[Image:XJDemo v3.1.png]] =Running the XJDemo version 2.0 demo on the XJDemo version 1.2 card= We are using version 1.2 XJDemo board (most likely version 1.2). The main functional differences are: # The RAM circuit is a Holtek HT6116 2Kx8 bit as opposed to the BS62LV256SC on the v2.0 board. Refer to the schematic for the pinmapping for page 11 of the tutorial. # The ADC is not available on the v1.2 board # The jumper between the Altera and Xilinx device is not present on the v1.2 board You can download the modified tutorial files from [http://web.ift.uib.no/~kjetil/wiki/XJTAG%20Demo%20Board.zip here]. The tutorial aims to give you an understanding the process of creating an XJEase test system for a circuit, and the XJEase design philosophy. The tutorial can be navigated through the "Previous", "Home" and "Next" buttons at the top and bottom of each page in the tutorial. The structure of the tutorial is as follows: ==Circuit description== The tutorial begins with a description of the XJDemo board and links to the data sheets for each of the components in the circuit. ==Creating the project file== You will use XJDeveloper to create an XJEase description of the XJDemo board. This section explains how the various pieces of information are used, and what information can be gained from XJTAG automatically while creating the project file. ==Running the connection test== We run a connection test and demonstrate various types of error detection using the XJDemo board. ==Simple device testing== We create simple scripts to test the push buttons and LEDs. This illustrates the simplicity of programming in the XJEase language. ==More complex device testing== We test the memory device, by creating a script that contains the read and write cycles for the device, along with a simple memory test that uses these functions. ==Design reuse== Using a standard memory test and some standard IIC interface code, we quickly create some tests for the BS62LV256 static RAM and the EEPROM. ==DFT Analysis== The demo script is analysed to check the coverage of the test code and find out where extra tests need to be applied to improve the testability of the board. =Additional resources= [[XJTAG_for_new_prototypes]] [[Category:Mikroelektronikk]] 61f5babb61ae8fe7c200520dd17dd5f486c0b997 2824 2823 2021-02-22T16:38:51Z Lra034 110 wikitext text/x-wiki =XJDeveloper Tutorial= You should run the tutorial XJDeveloper tutorial (you can search for the app, or it can be found under XJTAG 3.10 in the windows start meny), the tutorial contains a detailed description on what to do. The program this tutorial is designed for is called XJDeveloper 3.10. In this tutorial you can choose between version 4.2 and 3.1 of the XJDemo board, we are using version 3.1. The tutorial provides a turtorial3.zip file with the files you're going to use. Unzip this to a new folder for your project. Below are a pictures of versions 3.1 of the XJDemo board. [[Image:XJDemo v3.1.png]] =XJLink Manager= XJLink Manager can be used to check if the XJDemo Board is properly connected and that the license is set correctly. You can open the program from the XJ-icon on the right side of the windows taskbar. If everything is fine the XJTask Manager should look like this: [[Image:XJLink Manager.png]] =Additional resources= [[XJTAG_for_new_prototypes]] [[Category:Mikroelektronikk]] da2d1602aaa04efdd968a54e040626ddc3ff900e 2826 2824 2021-02-22T16:41:55Z Lra034 110 /* XJDeveloper Tutorial */ wikitext text/x-wiki =XJDeveloper Tutorial= You should run the tutorial XJDeveloper Tutorial (you can search for the app, or it can be found under XJTAG 3.10 in the windows start meny), the tutorial contains a detailed description on what to do. The program this tutorial is designed for is called XJDeveloper 3.10. In this tutorial you can choose between version 4.2 and 3.1 of the XJDemo board, we are using version 3.1. The tutorial provides a turtorial3.zip file with the files you're going to use. Unzip this to a new folder for your project. Below are a pictures of versions 3.1 of the XJDemo board. [[Image:XJDemo v3.1.png]] =XJLink Manager= XJLink Manager can be used to check if the XJDemo Board is properly connected and that the license is set correctly. You can open the program from the XJ-icon on the right side of the windows taskbar. If everything is fine the XJTask Manager should look like this: [[Image:XJLink Manager.png]] =Additional resources= [[XJTAG_for_new_prototypes]] [[Category:Mikroelektronikk]] 2c9117f080ab2d3244572518808d44a7584f0044 6 690 2825 2021-02-22T16:39:27Z Lra034 110 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 139 2827 2785 2021-02-26T21:01:24Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 12:00, on zoom, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics). This includes 2016-2017 Bergen-Oslo meetings. https://indico.cern.ch/category/7495/ Grieg project meetings, UiB+UW are here: https://wiki.uib.no/ift/index.php/EarlyUniverseProjectMeetings Norwegian Center for CERN Related Research meetings (most of them protected in 2021) are here: https://indico.cern.ch/category/13574/ Old and not updated Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here (I still keep it for a while): https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2018 === "Spatind conference", Nordic Bi-annual conference in High Energy Physics, 2-8 January 2018 [https://indico.cern.ch/event/666278/ web page] Please register ASAP. you are (most probably) funded by the HEPP project. * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] b0dbd9fbb9d160979ceed188646ecb248979d8b5 2838 2827 2021-03-24T19:57:01Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 12:00, on zoom, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics). https://indico.cern.ch/category/7495/ Grieg project meetings, UiB+UW are here: https://wiki.uib.no/ift/index.php/EarlyUniverseProjectMeetings Norwegian Center for CERN Related Research meetings (most of them protected in 2021) are here: https://indico.cern.ch/category/13574/ Old and not updated Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here (I still keep it for a while): https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2018 === "Spatind conference", Nordic Bi-annual conference in High Energy Physics, 2-8 January 2018 [https://indico.cern.ch/event/666278/ web page] Please register ASAP. you are (most probably) funded by the HEPP project. * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 67084fb2948eb325a7a96d603e7331b032003b44 2839 2838 2021-03-24T20:02:29Z Nfyal 26 wikitext text/x-wiki == Seminar and meeting information == Our group meetings (some) are at 12:00, on zoom, wednesdays, look for specified category. Categories "BERGEN-HEPP", "BERGEN SUSY and DM" etc etc will be used as these meetings are already booked, but the subjects discussed will depend on the meeting and can be pertinent to all HEPP project members (High Energy Particle Physics). https://indico.cern.ch/category/7495/ Grieg project meetings (grieg2020), UiB+UW are here: https://wiki.uib.no/ift/index.php/EarlyUniverseProjectMeetings Norwegian Center for CERN Related Research meetings (most of them protected in 2021) are here: https://indico.cern.ch/category/13574/ Old and not updated Twiki for common ATLAS-SUSY Oslo-Bergen meetings can be found here (I still keep it for a while): https://twiki.cern.ch/twiki/bin/viewauth/Atlas/AtlasSUSYNorway == Particle Physics Group Meetings/Seminars/Tutorials == Click the dates for seminar details (slides, etc) === 2018 === "Spatind conference", Nordic Bi-annual conference in High Energy Physics, 2-8 January 2018 [https://indico.cern.ch/event/666278/ web page] Please register ASAP. you are (most probably) funded by the HEPP project. * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] === 2017 === EPS conference in particle physics, July 5-11, Venice: [http://eps-hep2017.eu/ web page] First circular [[File:EPS-FirstCircular.txt]] === 2016 === * ATLAS Higgs and tau workshop in Sheffield, October, [ https://indico.cern.ch/event/559951/timetable/#20161024 indico page] * PhD course on flavor physics, Copenhagen [https://indico.nbi.ku.dk/conferenceDisplay.py?confId=897 indico page], November. * Nordic b-annual particle physics meeting http://www.hip.fi/spatind2016 === 2015 === Look into https://indico.cern.ch/category/2/ for BERGEN or ATLAS Norway ECFA meeting in Norway, October 2015 https://indico.cern.ch/event/403355/timetable/#20151002.detailed Group outing in Ustaoset 11-13 December 2015: https://indico.cern.ch/event/458080/ === 2012 === Group presentation for Geir Anton visit at CERN, Feb 2012<br> *Wolfgang Liebig, Atlas Analysis and Computing [[File:ATLAScomp+anal.pdf]] *Heidi Sandaker, Damara progress report [[File:Damara.pdf]] *Anna Lipniacka ATLAS@UiB [[File:atlasuib2012.pdf]] === 2011 === Special pensum course: Introduction to ATLAS<br> November 2011<br> Wolfgang Liebig (Wolfgang.Liebig at cern.ch) * ATLAS detector [[File:ATLASdetector.pdf]] * ATLAS physics [[File:ATLASphyics.pdf]] * ATLAS reconstruction and performance [[File:ATLASperformance.pdf]] * ATLAS tools and practicalities [[File:ATLAStools.pdf]] === 2009 === * [[December 9 2009 seminar - Top quark charge]] * [[December 2 2009 seminar - Theory]] * [[November 25 2009 seminar - Bs to mu,mu and Blackholes]] * [[November 4 2009 seminar - 3D detectors and the lab]] * [[October 14 2009 seminar - taus]] * [[October 9 2009 review - poster session]] * [[Shifts/OTP/fimm group meeting May 5, 2009]] * [[SUSY/Tau analysis meeting March 12, 2009]] * [[Mini parallab workshop, March 19, 2009]] 4b643abc5174ae5f712ca3038b202b45ede26b94 0 137 2828 2787 2021-02-26T21:05:00Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics is funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway. The last funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report (not the final version alas) from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] eb755f67037b98452edb3489fd5baf0ffafc69a3 2840 2828 2021-03-24T22:29:43Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas0.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics was funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway until 2020. Now we are a part of Center for CERN Related Research. HistorY: The last HEPP funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 573bcea19223f2afe9b25b3772543d9e0c9dd9d5 2844 2840 2021-05-23T15:45:16Z Nfyal 26 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas2.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics was funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway until 2020. Now we are a part of Center for CERN Related Research. HistorY: The last HEPP funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 793fa0091a8c9a3256df42c4618024e47114827a 2858 2844 2021-09-07T11:50:39Z Jdj005 113 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. . (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas2.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics was funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway until 2020. Now we are a part of Center for CERN Related Research. HistorY: The last HEPP funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). We are also involved in the [http://www.cta-observatory.org/ Cherenkov Telescope Array]. [[Cherenkov_Telescope_Array_-_Norway|Click here for more info]]. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[ The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page ] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page ]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== all our jobs are listed in [jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here ] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [ http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 163b58b8180a674fe2d50a7ae94b662736d8d4de 0 234 2829 2801 2021-02-26T21:10:52Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] bb7bd2ed5729053c0491553301b4ad29cade126a 2830 2829 2021-02-26T21:11:56Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[http://web.ift.uib.no/~lipniack/Thesis_ThereseSjursen_April11_2014.pdf]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 . Search for Dark Matter produced in association with a Higgs boson decaying to tau leptons at s√ = 13 TeV with the ATLAS detector [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] d691d462952d936baf5b4e4003c9c78863ec125c 2831 2830 2021-02-27T21:47:37Z Nfyal 26 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[https://cds.cern.ch/record/1955577]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 . Search for Dark Matter produced in association with a Higgs boson decaying to tau leptons at s√ = 13 TeV with the ATLAS detector [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 72cd93caf93fdba4a00ebceb9e96510d882942a5 2846 2831 2021-06-30T09:53:55Z Nfyst 67 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[https://cds.cern.ch/record/1955577]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 . Search for Dark Matter produced in association with a Higgs boson decaying to tau leptons at s√ = 13 TeV with the ATLAS detector [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Wai Chun Leung: A Setup for Testing of Silicon Pixel Modules for the ITk Tracker in the ATLAS Experiment at CERN, June 2021. * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] e3758da88d0138220701ac13b44e7cf5c213f9ff 2848 2846 2021-06-30T09:57:48Z Nfyst 67 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[https://cds.cern.ch/record/1955577]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 . Search for Dark Matter produced in association with a Higgs boson decaying to tau leptons at s√ = 13 TeV with the ATLAS detector [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Wai Chun Leung: A Setup for Testing of Silicon Pixel Modules for the ITk Tracker in the ATLAS Experiment at CERN, June 2021. [[File:Master_thesis_Wai_Chun.pdf]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 553dcc1331d047aa3148406999a0f44f36dbd78a 2849 2848 2021-06-30T10:50:05Z Nfyst 67 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[https://cds.cern.ch/record/1955577]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 . Search for Dark Matter produced in association with a Higgs boson decaying to tau leptons at √s = 13 TeV with the ATLAS detector [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Wai Chun Leung: A Setup for Testing of Silicon Pixel Modules for the ITk Tracker in the ATLAS Experiment at CERN, June 2021. [[File:Master_thesis_Wai_Chun.pdf]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 3c7417e782ecf734fb26eaa4f86411bc26661aa3 2850 2849 2021-08-27T12:19:22Z Nfyst 67 wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[https://cds.cern.ch/record/1955577]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 . Search for Dark Matter produced in association with a Higgs boson decaying to tau leptons at √s = 13 TeV with the ATLAS detector [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Wai Chun Leung: A Setup for Testing of Silicon Pixel Modules for the ITk Tracker in the ATLAS Experiment at CERN, June 2021. [[File:Master_thesis_Wai_Chun.pdf]] * Tor Gunnar Hagen: A Search for the Higgs Boson in decays to e+e- using data from the ATLAS detector (June 2021) [[https://bora.uib.no/bora-xmlui/handle/11250/2770402]] * Rasmus Brekke: A study of mass reconstruction in Higgs to mu mu (June 2021) [[https://bora.uib.no/bora-xmlui/handle/11250/2771475]] * Sigurd Riis Haugen: Reconstruction of Charged Particle Tracks in Simulated Test Beams (August 2021). * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 2ab6317d3b48c45d4aa74362d9a332bd943cac9a 2866 2850 2022-01-17T09:22:42Z Nfo058 90 /* Defended Master theses */ wikitext text/x-wiki == Theses, Notes, Publications,Public Software ... == === Software === * SUSY scanner by Jan Lindroos [[https://github.com/JanLindroos/SUSYScanner ]] === Submitted and yet not defended Phd Thesis=== === Defended PhD theses === *Arshak Tonoyan - February 3rd 2012, Recreating the Top Quark: Commissioning and monitoring of the ATLAS Inner Detector and search for New Physics with heavy particles. [[File:Arshak_Thesis.pdf]] *Peter Rosendahl - Searching for the Higgs Boson in Pairs of tau Leptons in Data from the ATLAS Experiment (October 2013). [http://bora.uib.no/handle/1956/6382] *Therese Sjursen -Defended in June 2014, Search for Supersymmetry with Tau Leptons in Data from the ATLAS Experiment at the LHC. [[https://cds.cern.ch/record/1955577]] *Alex Kastanas October 2014, defended 12/12/14 Monitoring and Measurements with the ATLAS Inner Detector and Search for Supersymmetry using ATLAS data, [[File:ThesisMain_AlexKastanas.pdf]] * Jan Lindros, May 2016, Beyond the Standard Models in Particle Physics and Cosmology [[File:PhDthesis-jan-lindroos.pdf]] *Orjan Dale, June 2016, 24/06/2016 Searching for Dark Matter with the ATLAS and CTA Experiments [[File:PhDthesis_Dale-1.pdf]] * Justas Zalieckas, 2016, Determination of the ratio of b-quark fragmentation fractions f_s/f_d and study of the Higgs boson production and couplings with the ATLAS detector in pp collisions. [ * Steffen Mæland, April 2018, 'Pixel detector performance and study of CP invariance in H to tau tau decays with the ATLAS detector' [http://bora.uib.no/handle/1956/18106] * Nikolai Fomin, 2020 "Searches for sbottom quarks decaying to SM Higgs in ATLAS Run 2 data" [[File:Nikolai-thesis-final.pdf]] === Defended Master theses === * Kent-Olav Skjei - Atlas Detector Monitoring with Jets - Novmber 11th 2009 - [[File:Kent-Olav_Skjei-Thesis.pdf]] [[File:Kent-Olav_Skjei-MasterPresentation.pdf]] * Hilde Skjerdal - A Study of possible signatures for slow, heavily ionising particles in ATLAS * Maren Ugland - Measurement of the Bs mass in Bs -> J/ψφ -> μ+μ−K+K−, and physics validation with J/ψ events in ATLAS - September 25th 2008 - [[File:Maren_Ugland-Master_Thesis.pdf]] [[File:thesis_presentation.pdf]] * Alex Kastanas - Determination of invariant mass end-points in the mSUGRA coannihilation region - June 27th 2008 - [[File:Alex_Kastanas-Master_Thesis.pdf]] * Therese Sjursen - Search for SUSY signals with τ-leptons in the ATLAS detector - February 2008 - [[File:Therese_Sjursen-Master_Thesis.pdf]] * Øyvind Sætre - Construction, Testing and First Data Analysis with the Cosmic Ray Telescope - November 15th 2007 - [[File:Oyvind_Saetre-Master_Thesis.pdf]] * Kristine Helle- - June 1st 2010 -[[File:thesis_Helle.pdf]] * Anita Olausen- - June 1st 2010 - Måling av forholdet mellom ladning og masse for elektronet (not atlas) * Jørn H. Mæland- - June 1st 2010 -[[File:thesis_Maeland.pdf]] * Ørjan Svandal- - June 1st 2010 -[[File:thesis_Svandal.pdf]] * Alette Aasvold- A study of mass reconstruction in Z°→τ+τ- June 1st 2010 -[[File:thesis_aasvold.pdf]] * [[Orjan Dale - Master Thesis]][[File:thesis_orjan_dale.pdf]] * Justas Zalieckas 2012: Observation of the decays B⁰_s -> J/psi phiphi and B⁰_s -> J/psi K^*0 in the ATLAS detector * Steffen Mæland 2013: Study of the Bc meson properties with the ATLAS experiment * Muhammad Saddique Inam- The ATLAS and LHC ugrades. Some silicon pixel resuts, and study of possible graviton production. (June 2013) * Mayasa H Rashed August 2013: Measurement of radon concentrations and temperature profiles in boreholes (not Atlas) * Agnethe Seim Olsen - Master Thesis, Reaching Towards Higher Masses of Supersymmetric Particles Decaying to Tau Leptons, August 2014 [[http://web.ift.uib.no/~lipniack/Master_AgnetheSO.pdf]] * Simen Hellesund - June 1st 2016 . [[File:MasterSimenHellesund.pdf]] Search for lepton flavour violating H → μτ Higgs decays at 13 TeV * Magne Lauritzen - June 14th 2017 . [[File:MagneLauritzenMasters.pdf]] A Silicon Photomultiplier Based Readout System For A Cosmic Muon Telescope; Design And Implementation. The manal is here [[File:Manual_CRT.pdf]] * Andreas Heggelund - June 14th 2017 - [[http://bora.uib.no/handle/1956/16039]] Analysis of 3D Pixel Detectors for the ATLAS Inner Tracker Upgrade. * Are Træet - Sept 8th 2017. Study on viability of Gain Stabilization of SiPMs and determination of b-quark fragmentation fraction ratio fc/fu in pp collisions at sqrt(s) = 13 TeV. [[File:MasterAssignment-Are.pdf]] * Erlend Aakvaag, December 2020 . Search for Dark Matter produced in association with a Higgs boson decaying to tau leptons at √s = 13 TeV with the ATLAS detector [[https://bora.uib.no/bora-xmlui/handle/11250/2723789]] * Wai Chun Leung: A Setup for Testing of Silicon Pixel Modules for the ITk Tracker in the ATLAS Experiment at CERN, June 2021. [[File:Master_thesis_Wai_Chun.pdf]] * Tor Gunnar Hagen: A Search for the Higgs Boson in decays to e+e- using data from the ATLAS detector (June 2021) [[https://bora.uib.no/bora-xmlui/handle/11250/2770402]] * Rasmus Brekke: A study of mass reconstruction in Higgs to mu mu (June 2021) [[https://bora.uib.no/bora-xmlui/handle/11250/2771475]] * Sigurd Riis Haugen: Reconstruction of Charged Particle Tracks in Simulated Test Beams (August 2021). * Wai Kit Leung: Search for squarks in events with jets, hadronically decaying τ -lepton, and missing transverse momentum in the final state in proton-proton collision at s = 13 TeV with the ATLAS detector (September 2021) [[https://bora.uib.no/bora-xmlui/handle/11250/2780585]] * Some older atlas theses may be found here: [[http://folk.uib.no/nfyst/atlas_local.html]] =public presentations which are not in indico .. ==== *Steffen Maeland, Inga Strumke, machine learning to search for 2HDM, [[File:2hdmML.pdf]] 4fc2f47163dc34bb456f5318b0ac978d2a7d410a 0 481 2832 2671 2021-03-09T15:02:52Z Kaf003 107 wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> The presentation can also be found in the uvvm_util folder. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wena <= '0'; sbi_if.rena <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant alert_level : in t_alert_level := error; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg, clk, sbi_if, alert_level, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] 00e731d527db8483993cca85ea3620533f47508d 2833 2832 2021-03-09T15:03:02Z Kaf003 107 Reverted edits by [[Special:Contributions/Kaf003|Kaf003]] ([[User talk:Kaf003|talk]]) to last revision by [[User:Put009|Put009]] wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> The presentation can also be found in the uvvm_util folder. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wena <= '0'; sbi_if.rena <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level := error; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, alert_level, msg, clk, sbi_if, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] 92833b53eed35233a8271fe235015a1b73959906 2834 2833 2021-03-09T15:04:22Z Kaf003 107 Changed position of alert_level to where it should be wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> The presentation can also be found in the uvvm_util folder. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wena <= '0'; sbi_if.rena <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant alert_level : in t_alert_level := error; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg, clk, sbi_if, alert_level, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] 00e731d527db8483993cca85ea3620533f47508d 2835 2834 2021-03-09T15:42:32Z Kaf003 107 Included the need to set sbi_if.ready signal high to avoid failure. wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> The presentation can also be found in the uvvm_util folder. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wena <= '0'; sbi_if.rena <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant alert_level : in t_alert_level := error; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg, clk, sbi_if, alert_level, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> We also need to set the sbi_if.ready signal high for this to work: <pre> clock_generator(clk, clock_ena, C_CLK_PERIOD, "IRQC TB clock"); -- Insert this here by the clock generator sbi_if.ready <= '1'; -- always ready in the same clock cycle. </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] 15f93ca60b44ed05218d270aa8a4cd8642fe67ab 2836 2835 2021-03-09T15:48:21Z Kaf003 107 Added some text recommending not including an overload wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> The presentation can also be found in the uvvm_util folder. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wena <= '0'; sbi_if.rena <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> This exact function is already overloaded in the UVVM packages, so including this in our testbench would produce compilation errors. So, let's not include it, but view it as an example of how it's done. Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant alert_level : in t_alert_level := error; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg, clk, sbi_if, alert_level, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> We also need to set the sbi_if.ready signal high for this to work: <pre> clock_generator(clk, clock_ena, C_CLK_PERIOD, "IRQC TB clock"); -- Insert this here by the clock generator sbi_if.ready <= '1'; -- always ready in the same clock cycle. </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] 14b6114b68b6f6a4cf01679b1505e4b9be503de5 0 679 2837 2804 2021-03-24T19:53:25Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] The project is financed by Norwegian Financial Mechanism, with the latest possible use of funds in 31 of March 2024. This is Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. === [[EarlyUniverseProjectShared|Sharing Ideas]] === === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === === [[PublicationsOfInterests| Presentations of Interest]] === Bergen particle physics group twiki: [[https://wiki.uib.no/ift/index.php/Particle_Physics_group Bergen particle physics]] People and tasks in the project: Research objectives: 1) Machine learning assisted mono-jet anlysis in search for Dark Matter and new electricaly neutral stable particles and its theoretical interpretation. [ K. Sakurai, B. M. dit Latour, I. Lara, K. Rolbiecki, M. Olechowski, S. Pokorski, T. Buanes, A. Lipniacka, K. Tywoniuk, R. Masełek] 2) Discriminating theories by joint mono-jet and mono-Higgs analysis. [ K. Rolbiecki, T. B. Sjursen, I. Lara, J. Rosiek, T. Buanes, A. Lipniacka, Nikolai Fomin, Erlend Aakvaag] 3) Constraining the mechanism of the Electroweak Phase Transition by di-Higgs boson production, p p -> h h. [ M. Olechowski, A. Lipniacka, S. Pokorski, Z. Lalak, B. Stugu] 4) Probing new sources of CP violation in the Higgs-fermion sector. [ J. Rosiek, B. Stugu, K. Rolbiecki, K. Sakurai, A. Lipniacka, Erlend Aakvaag] 5) Investigating the sphaleron and mini-black hole production at the LHC and its dependence on the mechanism of EWPT. [ S. Pokorski, T. Buanes, I. Lara, K. Sakurai, M. Olechowski, Z. Lalak, A. Lipniacka, K. Tywoniuk, R. Masełek] [[Image:grieg-logo.png]] 2ba8680e3aab63d13edbc31d09c72b01f47d2971 2851 2837 2021-09-02T08:49:28Z Nfyal 26 wikitext text/x-wiki == EarlyUniverse, GRIEG project == [https://www.fuw.edu.pl/~ksakurai/GRIEG_strona/index.html GRIEG project "EarlyUniverse" official web page] The project is financed by Norwegian Financial Mechanism, with the latest possible use of funds in 31 of March 2024. This is Wiki page for "EarlyUniverse" GRIEG project, with participants from Bergen High Energy Physics Group, and Particle Theory Group, University of Warsaw. To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail to Anna Lipniacka and she will figure out who can activate your account. If you are financed by the project you need to acknowledge it with the following slide in your presentations. here : [https://www.fuw.edu.pl/~ksakurai/grieg/universal_slide.pdf slide] === [[EarlyUniverseProjectShared|Sharing Ideas]] === === [[EarlyUniverseProjectMeetings|Meetings, Seminars & Tutorials]] === === [[PublicationsOfInterests| Presentations of Interest]] === Bergen particle physics group twiki: [[https://wiki.uib.no/ift/index.php/Particle_Physics_group Bergen particle physics]] People and tasks in the project: Research objectives: 1) Machine learning assisted mono-jet anlysis in search for Dark Matter and new electricaly neutral stable particles and its theoretical interpretation. [ K. Sakurai, B. M. dit Latour, I. Lara, K. Rolbiecki, M. Olechowski, S. Pokorski, T. Buanes, A. Lipniacka, K. Tywoniuk, R. Masełek] 2) Discriminating theories by joint mono-jet and mono-Higgs analysis. [ K. Rolbiecki, T. B. Sjursen, I. Lara, J. Rosiek, T. Buanes, A. Lipniacka, Nikolai Fomin, Erlend Aakvaag] 3) Constraining the mechanism of the Electroweak Phase Transition by di-Higgs boson production, p p -> h h. [ M. Olechowski, A. Lipniacka, S. Pokorski, Z. Lalak, B. Stugu] 4) Probing new sources of CP violation in the Higgs-fermion sector. [ J. Rosiek, B. Stugu, K. Rolbiecki, K. Sakurai, A. Lipniacka, Erlend Aakvaag] 5) Investigating the sphaleron and mini-black hole production at the LHC and its dependence on the mechanism of EWPT. [ S. Pokorski, T. Buanes, I. Lara, K. Sakurai, M. Olechowski, Z. Lalak, A. Lipniacka, K. Tywoniuk, R. Masełek] [[Image:grieg-logo.png]] 0a0451e1fc194d48ea923f4f60ba2b0c695701dc 6 691 2841 2021-05-07T14:07:17Z Hbi009 109 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 546 2842 2771 2021-05-07T14:08:18Z Hbi009 109 /* Post layout simulation */ wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] Note that there is a specified minimum enclosure in the design rules for vias between polysilicon and metal. This is because during the manufacturing process, the polysilicon and metal layers are created separately and the alignment is not perfect, so the polysilicon connection must be slightly larger to accommodate the potential offset between these layers. Enclosures can be seen by the polysilicon squares on the vias connecting the Q and Q_B lines in the design above. To set a via enclosure size, right click the via and go to properties. On the bottom, there is a setting for GatPoly enclosure. You must set each direction separately. = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. If you want to simulate corners with the ptap1 and ntap1 components, you have to add two additional model files for your corner simulation. The model files for IHP 130nm process is located in /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/tech/SG13_PASSIVES/spectre/ Add SG13_cornerCAP.scs and SG13_cornerRES.scs to your model files and click ok. Now you can add bcs(Best Case Scenario) and wcs (Worst Case Scenario) to each corner, remember to enable the "tick box" for each of them. When you are done, the corner setup should look something like this: [[File:Corner_setup.png|400px]] [[Category:Mikroelektronikk]] 43608af85bcfd220460a83b5644c6935b83e6d2f 2843 2842 2021-05-07T14:29:09Z Hbi009 109 /* Post layout simulation */ wikitext text/x-wiki = Before starting layout = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed"). = Layout XL = From the schematic click Launch -> Layout XL to open the layout environment. [[File:layout.png|200px]] [[File:layout2.png|200px]] Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted. Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc. [[File:grid.png|200px]] [[File:gravity.png|200px]] = Generate from source = IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed. Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results. [[File:result.png|600px]] The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window. = Pin Placement = Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later. [[File:pinplacement.png|400px]] = Placing devices = If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device. F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part. [[File:partial.png|50px]] [[File:partial2.png|50px]] == DRD == [[File:DRDbuttons.png|50px]] DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify. [[File:DRD.png|200px]] == Drawing == To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking. A complete layout could look something like this: [[File:sram.png|600px]] Note that there is a specified minimum enclosure in the design rules for vias between polysilicon and metal. This is because during the manufacturing process, the polysilicon and metal layers are created separately and the alignment is not perfect, so the polysilicon connection must be slightly larger to accommodate the potential offset between these layers. Enclosures can be seen by the polysilicon squares on the vias connecting the Q and Q_B lines in the design above. To set a via enclosure size, right click the via and go to properties. On the bottom, there is a setting for GatPoly enclosure. You must set each direction separately. = DRC = Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear: [[File:drcok.png|200px]] The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design. = LVS = This is covered in chapter 12 of the user guide. Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors. [[File:LVS_summary.png|200px]] = Parasitic extraction QRC = This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match. To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK. [[File:ASSURA_QRC.png|400px]] This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver. [[File:Extracted_layout_SRAM_with_bt_wd.png|400px]] = Post layout simulation = In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor. Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed. Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted. [[File:Hierarchy_editor.png|400px]] Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it. If you want to simulate corners with the ptap1 and ntap1 components, you have to add two additional model files for your corner simulation. These model files for IHP 130nm process is located in /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/tech/SG13_PASSIVES/spectre/ Add SG13_cornerCAP.scs and SG13_cornerRES.scs to your model files and click ok. Now you can add bcs(Best Case Scenario) and wcs (Worst Case Scenario) to each corner, remember to enable the "tick box" for each of them. When you are done, the corner setup should look something like this: [[File:Corner_setup.png|400px]] [[Category:Mikroelektronikk]] d4fc0b737831a72986f3e835b4a05ac035b4a90d 0 572 2845 2728 2021-06-21T12:36:10Z Gge002 52 wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. ==List of sealed sources at the IFT== ===Storage 4=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 4 #1 | ²⁴¹Am | 27 | 1 000 | 2006 | 458 y | 60 keV gamma | OI428/Code: AMRB 13788 |- | 2 | Storage 4 #2 | ⁵⁷Co | 100 | 3 700 | 2006 | 272 d | 122 keV gamma | Code: CTR 8252 |- | 3 | Storage 4 #3 | ¹³³Ba | 100 | 3 700 | 2006 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Code: BDR 8252 |- | 4 | Storage 4 #4 | ¹⁵⁵Eu | 100 | 3 700 | 1993 | 4.8 y | 105 keV gamma | |- | 5 | Storage 4 #5 | ²²⁶Ra | 2.7 | 100 | ~1970 | 1 600 y | 186 keV gamma | |- | 6 | Storage 4 #6 | ¹³⁷Cs | 60 | 2 200 | 1986 | 30 y | 662 keV gamma | |- | 7 | Storage 4 #7 | ²⁴¹Am | 3 000 | 100 000 | 1977 | 458 y | 60 keV gamma | UB/FIB 539 |- | 8 | Storage 4 #8 | ²⁴¹Am | 10 000 | 370 000 | 1987 | 458 y | | Variable X-ray source |- | 9 | Storage 4 #9 | ⁵⁵Fe | 20 000 | 740 000 | N/A | 2.7 y | X-rays | Decayed |- | 10 | Storage 4 #10 | ¹⁰⁹Cd | 1 | 37 | 2011 | 427 d | 88 keV gamma | Calibr. Set Spectrum Techniques |- | 11 | Storage 4 #11 | ⁵⁷Co | 1 | 37 | 2011 | 272 d | 122 keV gamma | Calibr. Set Spectrum Techniques |- | 12 | Storage 4 #12 | ¹³³Ba | 1 | 37 | 2011 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. Set Spectrum Techniques |- | 13 | Storage 4 #13 | ⁶⁰Co | 1 | 37 | 2011 | 5.3 y | 1 173, 1 333 keV gamma | Calibr. Set Spectrum Techniques |- | 14 | Storage 4 #14 | ¹³⁷Cs | 1 | 37 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 15 | Storage 4 #15 | ²²Na | 1 | 37 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 16 | Storage 4 #16 | ¹³⁷Cs⁶⁵Zn | 1 | 37 | 2011 | 30 y + 244 d | 662 + 1 116 keV gamma | Calibr. Set Spectrum Techniques |- | 17 | Storage 4 #17 | ⁵⁴Mn | 1 | 37 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 18 | Storage 4 #18 | ¹³⁷Cs | 10 | 370 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 19 | Storage 4 #19 | ²²Na | 10 | 370 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 20 | Storage 4 #20 | ⁵⁴Mn | 10 | 370 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 21 | Storage 4 #21 | ¹³³Ba | 10 | 370 | 2012 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. source Eckert & Ziegler |- | 22 | Storage 4 #22 | ²⁴¹Am | 1 | 37 | 1990 | 458 y | 60 keV gamma | Laborel box (ruined and sagregated for disposal) |- | 23 | Storage 4 #23 | ¹⁰⁹Cd | 1 | 37 | 1990 | 427 d | 88 keV gamma | Laborel box |- | 24 | Storage 4 #24 | ¹³⁹Ce | 1 | 37 | 1990 | 138 d | 166 keV gamma | Laborel box |- | 25 | Storage 4 #25 | ⁵⁷Co | 1 | 37 | 1990 | 272 d | 122 keV gamma | Laborel box |- | 26 | Storage 4 #26 | ¹³⁷Cs | 1 | 37 | 1190 | 30 y | 662 keV gamma | Laborel box |- | 27 | Storage 4 #27 | ⁵¹Cr | 1 | 37 | 1990 | 27 d | 320 keV gamma | Laborel box |- | 28 | Storage 4 #28 | ⁵⁴Mn | 1 | 37 | 1990 | 312 d | 835 keV gamma | Laborel box |- | 29 | Storage 4 #29 | ¹¹³Sn | 1 | 37 | 1990 | 115 d | 255 keV gamma | Laborel box |- | 30 | Storage 4 #30 | ⁸⁵Sr | 1 | 37 | 1990 | 65 d | 355 keV gamma | Laborel box |- | 31 | Storage 4 #31 | ⁶⁵Zn | 1 | 37 | 1990 | 244 d | 1 116 keV gamma | Laborel box |- | 32 | Storage 4 #32 | ¹³³Ba | 4 000 | 148 000 | 2014 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Eckert & Ziegler, Brass holder |- | 33 | Storage 4 #33 | ⁹⁰Sr | 54 | 2 010 | 1993 | 29 y | e^- | DESY |- | 34 | Storage 4 #34 | ⁵⁵Fe | 1 000 | 37 000 | 2014 | 2.7 y | X-rays | UiB# 0218698 |- | 35 | Storage 4 #35a | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- | 36 | Storage 4 #35b | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- |} ===Storage 3=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 3 #1 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 2 | Storage 3 #2 | ¹³³Ba | 1 | 37 | 2013 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | |- | 3 | Storage 3 #3 | ²²Na | 1 | 37 | 2013 | 2.6 y | 511, 1 275 keV gamma | |- | 4 | Storage 3 #4 | ⁵⁷Co | 1 | 37 | 2013 | 272 d | 122 keV gamma | |- | 5 | Storage 3 #5a | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 6 | Storage 3 #5b | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 7 | Storage 3 #6 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 3 #7 | ²⁴¹Am | 1 | 37 | 1976 | 458 y | Alpha + 60 keV gamma | Glass tube set |- | 9 | Storage 3 #8 | ⁹⁰Sr | 1 | 37 | 1976 | 29 y | e^- | Glass tube set |- | 10 | Storage 3 #9 | ⁵⁵Fe | 10 | 370 | 1976 | 30 y | 662 keV gamma | Glass tube set |- | 11 | Storage 3 #10 | ¹⁰⁶Ru | 2.7 | 100 | 2000 | 374 d | e^- | |- | 12 | Storage 3 #11 | ²⁴¹Am | 10 | 370 | 1975 | 458 y | Alpha + 60 keV gamma | ORTEC AM-1U, S/N M-1343, act. 0.088 |- |} ===Storage 2=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 2 #1a | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 2 | Storage 2 #1b | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 3 | Storage 2 #1c | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 4 | Storage 2 #1d | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 5 | Storage 2 #1e | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 6 | Storage 2 #1f | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 7 | Storage 2 #2 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 2 #3a | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 9 | Storage 2 #3b | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 10 | Storage 2 #4a | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 11 | Storage 2 #4b | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 12 | Storage 2 #5a | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 13 | Storage 2 #5b | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 14 | Storage 2 #6 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 15 | Storage 2 #7 | ¹⁵²Eu | 0.04 | 1.5 | 2006 | 13.5 y | Many gamma lines | Sealed Liquid |- | 16 | Storage 2 #8a | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 17 | Storage 2 #8b | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 18 | Storage 2 #8c | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 19 | Storage 2 #9a | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 20 | Storage 2 #9b | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 21 | Storage 2 #9c | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 22 | Storage 2 #9d | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 23 | Storage 2 #10 | ¹⁵²Eu | 1 | 37 | 2005 | 13.5 y | Many gamma lines | |- | 24 | Storage 2 #11a | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 25 | Storage 2 #11b | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 26 | Storage 2 #11c | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 27 | Storage 2 #11d | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 28 | Storage 2 #12a | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 29 | Storage 2 #12b | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 30 | Storage 2 #12c | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 31 | Storage 2 #13 | ²⁴¹Am | 0.24 | 9 | N/A | 458 y | 60 keV gamma | GDM 625 |- | 32 | Storage 2 #14 | ¹³⁷Cs | 1.22 | 45 | N/A | 30 y | 662 keV gamma | GDM 134 |- | 33 | Storage 2 #15 | UO₂ | N/A | N/A | N/A | N/A | N/A | Nuclear fuel pellet (black cylinder in epoxy cube) |- |} ===Storage 1=== ====White==== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 1W #1 | ²⁴¹Am | 10 000 | 370 000 | | 458 y | X-rays | Variable X-ray source |- | 2 | Storage 1W #2 | ²⁴¹Am | 10 | 370 | 1993 | 458 y | 60 keV gamma | DA289 written on the source |- | 3 | Storage 1W #3 | ⁶⁰Co | 10 | 370 | 1970 | 10.5 y | 1 173, 1 333 keV gamma | A943F |- | 4 | Storage 1W #4 | ¹⁴⁷Pm | 10 000 | 370 000 | 1974 | 2.6 y | 76, 198 keV gamma | A1124/N11958 |- | 5 | Storage 1W #5 | ¹³⁷Cs | 10 | 370 | | 30 y | 662 keV gamma | S/N 15319; A919F |- | 6 | Storage 1W #6 | ⁶⁰Co | 1 | 37 | | 10.5 y | 1 173, 1 333 keV gamma | S/N 811-L-1 |- | 7 | Storage 1W #7 | ²⁴¹Am | 0.1 | 3.7 | 1966 | 458 y | 60 keV gamma | A922F; S/N M954 Ortec |- | 8 | Storage 1W #8 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 9 | Storage 1W #9 | ¹³⁷Cs | 100 | 3 700 | 1984 | 30 y | 662 keV gamma | |- | 10 | Storage 1W #10 | ²⁴¹Am | 14 000 | 518 000 | 1984 | 458 y | 60 keV gamma | M55005 |- | 11 | Storage 1W #11 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 12 | Storage 1W #12 | ²²⁶Ra | 5-10 | 185-370 | 1970 | 1 600 y | 186 keV gamma | A859F; Leybold in a jar |- | 13 | Storage 1W #13 | ¹³⁷Cs | <10 | <370 | 2005 | 30 y | 662 keV gamma | Isotope generator |- | 14 | Storage 1W #14a | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 15 | Storage 1W #14b | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 16 | Storage 1W #14c | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 17 | Storage 1W #15 | ⁹⁰Sr | 2 000 | 74 000 | 1987 | 29 y | e^- | Amersham (in a blue cylindrical collimator) |- | 18 | Storage 1W #16 | | | | 1945 | | | Hiroshima dust |- | 19 | | | 0 | 0 | 2005 | | | Eluting solution for Tilf #13 Isotope generator |- |} ====Black==== {| class="wikitable" |- ! Item ! Source ID ! Activity, counts/s* ! Note |- | 1 | Storage 1B #1 | ~20 | Storage 1B R. 1 |- | 2 | Storage 1B #2 | ~120 | Storage 1B G. 1 |- | 3 | Storage 1B #3 | ~60 | Storage 1B G. 2 |- | 4 | Storage 1B #4 | ~100 | Storage 1B G. 3 |- | 5 | Storage 1B #5 | ~10 | Storage 1B G. 4 |- | 6 | Storage 1B #6 | ~10 | Storage 1B G. 5 |- | 7 | Storage 1B #7 | ~0 | Storage 1B G. 6 |- | 8 | Storage 1B #8 | ~220 | Storage 1B G. 7 |- | 9 | Storage 1B #9 | ~150 | Storage 1B G. 8 |- | 10 | Storage 1B #10 | ~10 | Storage 1B G. 9 |- | 11 | Storage 1B #11 | ~350 | Storage 1B G. 10 |- | 12 | Storage 1B #12 | ~500 | Storage 1B G. 11 |- | 13 | Storage 1B #13 | ~1 000 | Storage 1B G. 12 |- |} <nowiki>*</nowiki>Activity measured with an 1" NaI(Tl) crystal 63621831cec795661ca4f24acbe014e306df79e4 6 692 2847 2021-06-30T09:55:29Z Nfyst 67 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 1 2852 2799 2021-09-07T11:21:45Z Jdj005 113 wikitext text/x-wiki =Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki= * [[DAMARA]] * [[Detector lab]] * [[Cherenkov Telescope Array - Norway]] * [[Eksperimentalfysikk med prosjektoppgave - PHYS117]] * [[Experimental Nuclear Physics group]] * [[Microelectronics group]] * [http://wiki.uib.no/nanolab Nano Lab] * [[Particle Physics group]] * [[GRIEG project "EarlyUniverse"]] * [[Strålevern]] * [[Teknisk avdeling]] == Komme i gang == * [[Få tilgang til å opprette eller redigere sider i wikien]] * [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] * [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] 43b4291aa95f153830b8499ff604bb82f908c739 0 693 2853 2021-09-07T11:24:00Z Jdj005 113 Created page with "Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] - a next level observatory for gamma ray astronomy." wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] - a next level observatory for gamma ray astronomy. ca95db5b2e1006b2f05e743e47044690b4b67957 2854 2853 2021-09-07T11:28:52Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have regular meetings and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Some youtube videos (the last one already introduces you to coding with gammapy. So you can also look at this later, once you know which software you will use): - Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU - Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida - Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs - Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS - More detailed talk on gammapy by Axel (this can be used for getting start with gammapy, so this really gets you set up for coding, etc. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU d20b32df4554b985e3635faa0dcd351957e2152c 2855 2854 2021-09-07T11:30:40Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have regular meetings and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Some youtube videos: - Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU - Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida - Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs - Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS - More detailed talk on gammapy by Axel (this can be used for getting start with gammapy, so this really gets you set up for coding, etc. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU 33eaaa299b59a2894b7da27b826b061343bd4cf8 2856 2855 2021-09-07T11:32:15Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have regular meetings and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU df2327906ba93c4add0617280e5223d0b15af4b6 2857 2856 2021-09-07T11:33:33Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU 540264eb217a303948a4a61d44516fb36df03a71 2859 2857 2021-09-14T07:53:10Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos 2df85befeee815a93e27453b3382d464c176e399 2860 2859 2021-09-14T07:57:48Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 aaae5422674ae3e58bee569c61f5ac9e1e108de6 2861 2860 2021-09-30T11:24:58Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 * Equatorial coordinate system explained: https://www.youtube.com/watch?v=WvXTUcYVXzI == Registering new arrivals == The group leader has to the name to this list: https://portal.cta-observatory.org/Bodies/ProjectOffice/Lists/People/Grouped.aspx and then an email has to be sent to Tiziana to ask for an account for the CTA web services. 72184734eda4ecc0b844cc55958465c33e3a9f79 2862 2861 2021-09-30T11:25:41Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. == Information for beginners == Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 * Equatorial coordinate system explained: https://www.youtube.com/watch?v=WvXTUcYVXzI = Registering new arrivals = The group leader has to add the name to this list: https://portal.cta-observatory.org/Bodies/ProjectOffice/Lists/People/Grouped.aspx and then an email has to be sent to Tiziana to ask for an account for the CTA web services. fe70ea3e33dfb45938e0d74e8f2edbc69fc8c99f 2863 2862 2021-09-30T11:26:06Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. = Information for beginners = Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 * Equatorial coordinate system explained: https://www.youtube.com/watch?v=WvXTUcYVXzI == Registering new arrivals == The group leader has to add the name to this list: https://portal.cta-observatory.org/Bodies/ProjectOffice/Lists/People/Grouped.aspx and then an email has to be sent to Tiziana to ask for an account for the CTA web services. 20a60435f46c37c4c0ed1c8db4c1d945ce127b31 2864 2863 2021-11-05T13:14:19Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. = Information for beginners = Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Introductory talk about DM searches at CTA: https://www.youtube.com/watch?v=g2tyOIsy1kQ * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 * Equatorial coordinate system explained: https://www.youtube.com/watch?v=WvXTUcYVXzI == Registering new arrivals == The group leader has to add the name to this list: https://portal.cta-observatory.org/Bodies/ProjectOffice/Lists/People/Grouped.aspx and then an email has to be sent to Tiziana to ask for an account for the CTA web services. 1fb2930b05e1e5554c94c676f9501d8471389b26 2865 2864 2021-12-03T08:43:08Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. = Information for beginners = Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Introductory talk about DM searches at CTA: https://www.youtube.com/watch?v=g2tyOIsy1kQ * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 * Equatorial coordinate system explained: https://www.youtube.com/watch?v=WvXTUcYVXzI * Rather lengthy and detailed introduction to the field: https://arxiv.org/abs/2111.01198 == Registering new arrivals == The group leader has to add the name to this list: https://portal.cta-observatory.org/Bodies/ProjectOffice/Lists/People/Grouped.aspx and then an email has to be sent to Tiziana to ask for an account for the CTA web services. aa1778718df1b9ac925d5feadaf2511f1b19ca3a 0 472 2867 2773 2022-08-24T12:25:44Z Are033 82 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver: ssh -X mikroserver5 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2019-20/scripts/analog.sh cd ~/ihp/cds/ source /eda/design_kits/ihp_sg13/sh.cadence virtuoso & To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] = Before starting designing = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] cf6253c5ad8bc35fcd98806bc8d35529c93378ae 0 38 2868 2561 2022-09-05T09:18:59Z Are033 82 wikitext text/x-wiki = IC design flow using Cadence = We have access to several silicon technologies from different foundries * 130nm CMOS process from Taiwan Semiconductor Manufacturing: '''[[ TSMC 130nm process ]]''' * 130nm SiGe process from Innovations for High Performance Microelectronics: '''[[ IHP 130nm process ]]''' * 350nm CMOS process from Austria Mikro Systeme: '''[[ AMS 350nm process ]]''' = Design entry using schematic capture = * Make sure you have set correct library. * Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/LIBRARY_VENDOR/') = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[MikroserverSetup]] - setup for easy connection to the mikroservers and Cadence Virtuoso [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[DCoperatingparameters]] - Guide for showing transistor operating points in the schematic [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 028c4b25c19bacb7e3e2464d0b7b3375c16e80c0 2869 2868 2022-09-06T08:01:50Z Are033 82 /* Design entry using schematic capture */ wikitext text/x-wiki = IC design flow using Cadence = We have access to several silicon technologies from different foundries * 130nm CMOS process from Taiwan Semiconductor Manufacturing: '''[[ TSMC 130nm process ]]''' * 130nm SiGe process from Innovations for High Performance Microelectronics: '''[[ IHP 130nm process ]]''' * 350nm CMOS process from Austria Mikro Systeme: '''[[ AMS 350nm process ]]''' = Design entry using schematic capture = * Make sure you have set correct library. * Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/LIBRARY_VENDOR/') [[Design entry|Virtuoso schematic editor]] = Simulation = [[Testbench|Virtuoso Testbench]] = Layout = [[Layout XL and IHP SG13S]] =Helpful stuff= [[MikroserverSetup]] - setup for easy connection to the mikroservers and Cadence Virtuoso [[ Transistor operating point printer ]] - Script to extract transistor operating point parameters after simulation. [[DCoperatingparameters]] - Guide for showing transistor operating points in the schematic [[ ADEXL-butterfly-curves ]] - Howto make DC butterfly curves easily. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 4a6de1a6e973fa7c759aedc42643846998aff1f1 0 694 2870 2022-09-06T08:05:42Z Are033 82 Created page with "Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == In the log window, choose "File > New > Library". In the "New Library" dialog box, you must g..." wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] 403ba06d035e33c0dc9177a55cd2c729ac3ce764 6 697 2873 2022-09-13T08:44:03Z Are033 82 wikitext text/x-wiki starting 9493af057b02387d97de1cd6b474270b6a80d658 0 694 2874 2870 2022-09-13T08:45:20Z Are033 82 wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == Start Cadence virtuoso environment by executing 'virtuoso &' from the directory where cds.lib file is located. Virtuoso starts with screen shown below:- [[File:Start virt.png|600px|Starting screen of virtuoso environment.]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] 5d9e69073fe4d5e6bd1221849c1dfa2ab08330db 2876 2874 2022-09-13T08:48:32Z Are033 82 /* Getting started */ wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == Start Cadence virtuoso environment by executing 'virtuoso &' from the directory where cds.lib file is located. Virtuoso starts with screen shown below:- [[File:Start virt.png|600px|Starting screen of virtuoso environment.]] Select 'Library manager' from 'Tools' in virtuoso environment --> Library manager starts with screen shown below:- [[File:Libmanager basic.png|600px|Starting screen of library manager]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] d68d8028c8477bcc5c13bb1a159ffd5db6b00066 2878 2876 2022-09-14T09:08:11Z Are033 82 /* Getting started */ wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == Start Cadence virtuoso environment by executing 'virtuoso &' from the directory where cds.lib file is located. Virtuoso starts with screen shown below:- [[File:Start virt.png|800px|Starting screen of virtuoso environment.]] Select 'Library manager' from 'Tools' in virtuoso environment --> Library manager starts with screen shown below:- [[File:Libmanager basic.png|800px|Starting screen of library manager]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:Invert 1.png|800px|Schematics of inverter in Cadence virtuoso]] e866e5568b13ca61c6338ebc0bdb447724f73408 2879 2878 2022-09-14T09:11:29Z Are033 82 wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == Start Cadence virtuoso environment by executing 'virtuoso &' from the directory where cds.lib file is located. Virtuoso starts with screen shown below:- [[File:Start virt.png|800px|Starting screen of virtuoso environment.]] Select 'Library manager' from 'Tools' in virtuoso environment --> Library manager starts with screen shown below:- [[File:Libmanager basic.png|800px|Starting screen of library manager]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:Invert 1.png|800px|Schematics of inverter in Cadence virtuoso]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. 273eb3c782b8dc5a9d2f8c2c6db261ad7169bf63 2880 2879 2022-09-14T09:29:13Z Are033 82 wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == Start Cadence virtuoso environment by executing 'virtuoso &' from the directory where cds.lib file is located. Virtuoso starts with screen shown below:- [[File:Start virt.png|800px|Starting screen of virtuoso environment.]] Select 'Library manager' from 'Tools' in virtuoso environment --> Library manager starts with screen shown below:- [[File:Libmanager basic.png|800px|Starting screen of library manager]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:Invert 1.png|800px|Schematics of inverter in Cadence virtuoso]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. ==Simulating the design== # Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 94748017500682b45077f292a825d8048a53a9d7 2883 2880 2022-09-28T09:09:07Z Are033 82 /* Simulating the design */ wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == Start Cadence virtuoso environment by executing 'virtuoso &' from the directory where cds.lib file is located. Virtuoso starts with screen shown below:- [[File:Start virt.png|800px|Starting screen of virtuoso environment.]] Select 'Library manager' from 'Tools' in virtuoso environment --> Library manager starts with screen shown below:- [[File:Libmanager basic.png|800px|Starting screen of library manager]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:Invert 1.png|800px|Schematics of inverter in Cadence virtuoso]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. ==Simulating the design== # Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|400px]] Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". # Note ratio between sizes of PMOS and NOMS, repeat simulation and observe changes in response for 4 different sizing ratios for example output waveforms for transient response of two different sizing ratios is shown below: [[File:PN ratio 1.png|800px|Transient response for PMOS NMOS size ratio=1]] [[File:PN ratio 4.png|800px|Transient response for PMOS NMOS size ratio=4]] ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 1e64d79d9c45da79e322c61d3aa7f33063473a65 2884 2883 2022-09-28T09:15:47Z Are033 82 /* Simulating the design */ wikitext text/x-wiki Copied/WiP (based on) from TSMC 180 flow of current wiki == Getting started == Start Cadence virtuoso environment by executing 'virtuoso &' from the directory where cds.lib file is located. Virtuoso starts with screen shown below:- [[File:Start virt.png|800px|Starting screen of virtuoso environment.]] Select 'Library manager' from 'Tools' in virtuoso environment --> Library manager starts with screen shown below:- [[File:Libmanager basic.png|800px|Starting screen of library manager]] In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:Invert 1.png|800px|Schematics of inverter in Cadence virtuoso]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. ==Simulating the design== # Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|400px]] Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". # Note ratio between sizes of PMOS and NOMS, repeat simulation and observe changes in response for 4 different sizing ratios for example output waveforms for transient response of two different sizing ratios is shown below: [[File:PN ratio 1.png|800px|Transient response for PMOS NMOS size ratio=1]] [[File:PN ratio 4.png|800px|Transient response for PMOS NMOS size ratio=4]] Understand the difference caused in transient response by variations of MOSFET sizes and ratio between PMOS and NMOS for the designed inverter. ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 4e0b0c034c63de7bdcb41f14869332860e9e8c55 6 698 2875 2022-09-13T08:47:38Z Are033 82 wikitext text/x-wiki library manager 062305774ddeafffdaf8a0c46937148d4a47a1a0 6 699 2877 2022-09-14T09:05:38Z Are033 82 wikitext text/x-wiki inverter 3013bf740e78e6b108b7858998ee0ef0f128c041 6 700 2881 2022-09-28T09:04:19Z Are033 82 wikitext text/x-wiki Size of PMOS and NMOS is same: ratio=1 2208974a8189fd9efe017ff7ecf23ee0c8746faf 6 701 2882 2022-09-28T09:07:29Z Are033 82 wikitext text/x-wiki Size ratio of PMOS and NMOS = 4 d75f4b10d5dff1b0a7e53b0adda67d74c5b8ecfe 6 702 2885 2022-09-29T08:04:02Z Are033 82 File uploaded with MsUpload wikitext text/x-wiki File uploaded with MsUpload a655f04485ff507c02499d137d22a0d3e0ea32c2 0 472 2886 2867 2022-09-29T08:04:37Z Are033 82 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver: ssh -X mikroserver5 The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/cadence/2019-20/scripts/analog.sh cd ~/ihp/cds/ source /eda/design_kits/ihp_sg13/sh.cadence To start Cadence Virtuoso : virtuoso & Example script [[:File:example_script.txt]] to run from_ "user"/ihp/cds/ To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] = Before starting designing = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] 56946367b43bdab534c4e1e1177a38cdfd6e977d 2907 2886 2024-05-30T11:47:50Z Nfyku 4 wikitext text/x-wiki =Cadence design with IHP 130nm process= ==Starting up the IHP SG13S Design Kit== The following steps describe how to install the Process Design Kit and start a new design. Log on to the mikroserver of choise ssh -X mikroserver The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly. The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp) cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing: source /eda/design_kits/ihp_sg13/sh.cadence cd ~/ihp/cds/ source /eda/design_kits/ihp_sg13/sh.cadence To start Cadence Virtuoso : virtuoso & Example script [[:File:example_script.txt]] to run from_ "user"/ihp/cds/ To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]] = Before starting designing = Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found. Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/" [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]] a92ac0d91fdebef371d1455e6d4abff55f896a35 0 572 2887 2845 2022-10-27T06:21:19Z Sya081 50 /* List of sealed sources at the IFT */ wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. ==List of sealed sources at the IFT== ===Storage 4=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 4 #1 | ²⁴¹Am | 27 | 1 000 | 2006 | 458 y | 60 keV gamma | OI428/Code: AMRB 13788 |- | 2 | Storage 4 #2 | ⁵⁷Co | 100 | 3 700 | 2006 | 272 d | 122 keV gamma | Code: CTR 8252 |- | 3 | Storage 4 #3 | ¹³³Ba | 100 | 3 700 | 2006 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Code: BDR 8252 |- | 4 | Storage 4 #4 | ¹⁵⁵Eu | 100 | 3 700 | 1993 | 4.8 y | 105 keV gamma | |- | 5 | Storage 4 #5 | ²²⁶Ra | 2.7 | 100 | ~1970 | 1 600 y | 186 keV gamma | |- | 6 | Storage 4 #6 | ¹³⁷Cs | 60 | 2 200 | 1986 | 30 y | 662 keV gamma | |- | 7 | Storage 4 #7 | ²⁴¹Am | 3 000 | 100 000 | 1977 | 458 y | 60 keV gamma | UB/FIB 539 |- | 8 | Storage 4 #8 | ²⁴¹Am | 10 000 | 370 000 | 1987 | 458 y | | Variable X-ray source |- | 9 | Storage 4 #9 | ⁵⁵Fe | 20 000 | 740 000 | N/A | 2.7 y | X-rays | Decayed |- | 10 | Storage 4 #10 | ¹⁰⁹Cd | 1 | 37 | 2011 | 427 d | 88 keV gamma | Calibr. Set Spectrum Techniques |- | 11 | Storage 4 #11 | ⁵⁷Co | 1 | 37 | 2011 | 272 d | 122 keV gamma | Calibr. Set Spectrum Techniques |- | 12 | Storage 4 #12 | ¹³³Ba | 1 | 37 | 2011 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. Set Spectrum Techniques |- | 13 | Storage 4 #13 | ⁶⁰Co | 1 | 37 | 2011 | 5.3 y | 1 173, 1 333 keV gamma | Calibr. Set Spectrum Techniques |- | 14 | Storage 4 #14 | ¹³⁷Cs | 1 | 37 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 15 | Storage 4 #15 | ²²Na | 1 | 37 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 16 | Storage 4 #16 | ¹³⁷Cs⁶⁵Zn | 1 | 37 | 2011 | 30 y + 244 d | 662 + 1 116 keV gamma | Calibr. Set Spectrum Techniques |- | 17 | Storage 4 #17 | ⁵⁴Mn | 1 | 37 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 18 | Storage 4 #18 | ¹³⁷Cs | 10 | 370 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 19 | Storage 4 #19 | ²²Na | 10 | 370 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 20 | Storage 4 #20 | ⁵⁴Mn | 10 | 370 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 21 | Storage 4 #21 | ¹³³Ba | 10 | 370 | 2012 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. source Eckert & Ziegler |- | 22 | Storage 4 #22 | ²⁴¹Am | 1 | 37 | 1990 | 458 y | 60 keV gamma | Laborel box (ruined and sagregated for disposal) |- | 23 | Storage 4 #23 | ¹⁰⁹Cd | 1 | 37 | 1990 | 427 d | 88 keV gamma | Laborel box |- | 24 | Storage 4 #24 | ¹³⁹Ce | 1 | 37 | 1990 | 138 d | 166 keV gamma | Laborel box |- | 25 | Storage 4 #25 | ⁵⁷Co | 1 | 37 | 1990 | 272 d | 122 keV gamma | Laborel box |- | 26 | Storage 4 #26 | ¹³⁷Cs | 1 | 37 | 1990 | 30 y | 662 keV gamma | Laborel box |- | 27 | Storage 4 #27 | ⁵¹Cr | 1 | 37 | 1990 | 27 d | 320 keV gamma | Laborel box |- | 28 | Storage 4 #28 | ⁵⁴Mn | 1 | 37 | 1990 | 312 d | 835 keV gamma | Laborel box |- | 29 | Storage 4 #29 | ¹¹³Sn | 1 | 37 | 1990 | 115 d | 255 keV gamma | Laborel box |- | 30 | Storage 4 #30 | ⁸⁵Sr | 1 | 37 | 1990 | 65 d | 355 keV gamma | Laborel box |- | 31 | Storage 4 #31 | ⁶⁵Zn | 1 | 37 | 1990 | 244 d | 1 116 keV gamma | Laborel box |- | 32 | Storage 4 #32 | ¹³³Ba | 4 000 | 148 000 | 2014 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Eckert & Ziegler, Brass holder |- | 33 | Storage 4 #33 | ⁹⁰Sr | 54 | 2 010 | 1993 | 29 y | e^- | DESY |- | 34 | Storage 4 #34 | ⁵⁵Fe | 1 000 | 37 000 | 2014 | 2.7 y | X-rays | UiB# 0218698 |- | 35 | Storage 4 #35a | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- | 36 | Storage 4 #35b | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- |} ===Storage 3=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 3 #1 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 2 | Storage 3 #2 | ¹³³Ba | 1 | 37 | 2013 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | |- | 3 | Storage 3 #3 | ²²Na | 1 | 37 | 2013 | 2.6 y | 511, 1 275 keV gamma | |- | 4 | Storage 3 #4 | ⁵⁷Co | 1 | 37 | 2013 | 272 d | 122 keV gamma | |- | 5 | Storage 3 #5a | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 6 | Storage 3 #5b | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 7 | Storage 3 #6 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 3 #7 | ²⁴¹Am | 1 | 37 | 1976 | 458 y | Alpha + 60 keV gamma | Glass tube set |- | 9 | Storage 3 #8 | ⁹⁰Sr | 1 | 37 | 1976 | 29 y | e^- | Glass tube set |- | 10 | Storage 3 #9 | ⁵⁵Fe | 10 | 370 | 1976 | 30 y | 662 keV gamma | Glass tube set |- | 11 | Storage 3 #10 | ¹⁰⁶Ru | 2.7 | 100 | 2000 | 374 d | e^- | |- | 12 | Storage 3 #11 | ²⁴¹Am | 10 | 370 | 1975 | 458 y | Alpha + 60 keV gamma | ORTEC AM-1U, S/N M-1343, act. 0.088 |- |} ===Storage 2=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 2 #1a | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 2 | Storage 2 #1b | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 3 | Storage 2 #1c | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 4 | Storage 2 #1d | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 5 | Storage 2 #1e | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 6 | Storage 2 #1f | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 7 | Storage 2 #2 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 2 #3a | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 9 | Storage 2 #3b | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 10 | Storage 2 #4a | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 11 | Storage 2 #4b | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 12 | Storage 2 #5a | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 13 | Storage 2 #5b | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 14 | Storage 2 #6 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 15 | Storage 2 #7 | ¹⁵²Eu | 0.04 | 1.5 | 2006 | 13.5 y | Many gamma lines | Sealed Liquid |- | 16 | Storage 2 #8a | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 17 | Storage 2 #8b | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 18 | Storage 2 #8c | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 19 | Storage 2 #9a | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 20 | Storage 2 #9b | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 21 | Storage 2 #9c | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 22 | Storage 2 #9d | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 23 | Storage 2 #10 | ¹⁵²Eu | 1 | 37 | 2005 | 13.5 y | Many gamma lines | |- | 24 | Storage 2 #11a | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 25 | Storage 2 #11b | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 26 | Storage 2 #11c | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 27 | Storage 2 #11d | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 28 | Storage 2 #12a | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 29 | Storage 2 #12b | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 30 | Storage 2 #12c | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 31 | Storage 2 #13 | ²⁴¹Am | 0.24 | 9 | N/A | 458 y | 60 keV gamma | GDM 625 |- | 32 | Storage 2 #14 | ¹³⁷Cs | 1.22 | 45 | N/A | 30 y | 662 keV gamma | GDM 134 |- | 33 | Storage 2 #15 | UO₂ | N/A | N/A | N/A | N/A | N/A | Nuclear fuel pellet (black cylinder in epoxy cube) |- |} ===Storage 1=== ====White==== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 1W #1 | ²⁴¹Am | 10 000 | 370 000 | | 458 y | X-rays | Variable X-ray source |- | 2 | Storage 1W #2 | ²⁴¹Am | 10 | 370 | 1993 | 458 y | 60 keV gamma | DA289 written on the source |- | 3 | Storage 1W #3 | ⁶⁰Co | 10 | 370 | 1970 | 10.5 y | 1 173, 1 333 keV gamma | A943F |- | 4 | Storage 1W #4 | ¹⁴⁷Pm | 10 000 | 370 000 | 1974 | 2.6 y | 76, 198 keV gamma | A1124/N11958 |- | 5 | Storage 1W #5 | ¹³⁷Cs | 10 | 370 | | 30 y | 662 keV gamma | S/N 15319; A919F |- | 6 | Storage 1W #6 | ⁶⁰Co | 1 | 37 | | 10.5 y | 1 173, 1 333 keV gamma | S/N 811-L-1 |- | 7 | Storage 1W #7 | ²⁴¹Am | 0.1 | 3.7 | 1966 | 458 y | 60 keV gamma | A922F; S/N M954 Ortec |- | 8 | Storage 1W #8 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 9 | Storage 1W #9 | ¹³⁷Cs | 100 | 3 700 | 1984 | 30 y | 662 keV gamma | |- | 10 | Storage 1W #10 | ²⁴¹Am | 14 000 | 518 000 | 1984 | 458 y | 60 keV gamma | M55005 |- | 11 | Storage 1W #11 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 12 | Storage 1W #12 | ²²⁶Ra | 5-10 | 185-370 | 1970 | 1 600 y | 186 keV gamma | A859F; Leybold in a jar |- | 13 | Storage 1W #13 | ¹³⁷Cs | <10 | <370 | 2005 | 30 y | 662 keV gamma | Isotope generator |- | 14 | Storage 1W #14a | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 15 | Storage 1W #14b | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 16 | Storage 1W #14c | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 17 | Storage 1W #15 | ⁹⁰Sr | 2 000 | 74 000 | 1987 | 29 y | e^- | Amersham (in a blue cylindrical collimator) |- | 18 | Storage 1W #16 | | | | 1945 | | | Hiroshima dust |- | 19 | | | 0 | 0 | 2005 | | | Eluting solution for Tilf #13 Isotope generator |- |} ====Black==== {| class="wikitable" |- ! Item ! Source ID ! Activity, counts/s* ! Note |- | 1 | Storage 1B #1 | ~20 | Storage 1B R. 1 |- | 2 | Storage 1B #2 | ~120 | Storage 1B G. 1 |- | 3 | Storage 1B #3 | ~60 | Storage 1B G. 2 |- | 4 | Storage 1B #4 | ~100 | Storage 1B G. 3 |- | 5 | Storage 1B #5 | ~10 | Storage 1B G. 4 |- | 6 | Storage 1B #6 | ~10 | Storage 1B G. 5 |- | 7 | Storage 1B #7 | ~0 | Storage 1B G. 6 |- | 8 | Storage 1B #8 | ~220 | Storage 1B G. 7 |- | 9 | Storage 1B #9 | ~150 | Storage 1B G. 8 |- | 10 | Storage 1B #10 | ~10 | Storage 1B G. 9 |- | 11 | Storage 1B #11 | ~350 | Storage 1B G. 10 |- | 12 | Storage 1B #12 | ~500 | Storage 1B G. 11 |- | 13 | Storage 1B #13 | ~1 000 | Storage 1B G. 12 |- |} <nowiki>*</nowiki>Activity measured with an 1" NaI(Tl) crystal 761f6cdfd55226d62c0b3c8906518b22bf372043 2892 2887 2022-11-25T14:46:05Z Sya081 50 wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. ==List of sealed sources at the IFT== ===Storage 4=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 4 #1 | ²⁴¹Am | 27 | 1 000 | 2006 | 458 y | 60 keV gamma | OI428/Code: AMRB 13788 |- | 2 | Storage 4 #2 | ⁵⁷Co | 100 | 3 700 | 2006 | 272 d | 122 keV gamma | Code: CTR 8252 |- | 3 | Storage 4 #3 | ¹³³Ba | 100 | 3 700 | 2006 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Code: BDR 8252 |- | 4 | Storage 4 #4 | ¹⁵⁵Eu | 100 | 3 700 | 1993 | 4.8 y | 105 keV gamma | |- | 5 | Storage 4 #5 | ²²⁶Ra | 2.7 | 100 | ~1970 | 1 600 y | 186 keV gamma | |- | 6 | Storage 4 #6 | ¹³⁷Cs | 60 | 2 200 | 1986 | 30 y | 662 keV gamma | |- | 7 | Storage 4 #7 | ²⁴¹Am | 3 000 | 100 000 | 1977 | 458 y | 60 keV gamma | UB/FIB 539 |- | 8 | Storage 4 #8 | ²⁴¹Am | 10 000 | 370 000 | 1987 | 458 y | | Variable X-ray source |- | 9 | Storage 4 #9 | ⁵⁵Fe | 20 000 | 740 000 | N/A | 2.7 y | X-rays | Decayed |- | 10 | Storage 4 #10 | ¹⁰⁹Cd | 1 | 37 | 2011 | 427 d | 88 keV gamma | Calibr. Set Spectrum Techniques |- | 11 | Storage 4 #11 | ⁵⁷Co | 1 | 37 | 2011 | 272 d | 122 keV gamma | Calibr. Set Spectrum Techniques |- | 12 | Storage 4 #12 | ¹³³Ba | 1 | 37 | 2011 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. Set Spectrum Techniques |- | 13 | Storage 4 #13 | ⁶⁰Co | 1 | 37 | 2011 | 5.3 y | 1 173, 1 333 keV gamma | Calibr. Set Spectrum Techniques |- | 14 | Storage 4 #14 | ¹³⁷Cs | 1 | 37 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 15 | Storage 4 #15 | ²²Na | 1 | 37 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 16 | Storage 4 #16 | ¹³⁷Cs⁶⁵Zn | 1 | 37 | 2011 | 30 y + 244 d | 662 + 1 116 keV gamma | Calibr. Set Spectrum Techniques |- | 17 | Storage 4 #17 | ⁵⁴Mn | 1 | 37 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 18 | Storage 4 #18 | ¹³⁷Cs | 10 | 370 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 19 | Storage 4 #19 | ²²Na | 10 | 370 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 20 | Storage 4 #20 | ⁵⁴Mn | 10 | 370 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 21 | Storage 4 #21 | ¹³³Ba | 10 | 370 | 2012 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. source Eckert & Ziegler |- | 22 | Storage 4 #22 | ²⁴¹Am | 1 | 37 | 1990 | 458 y | 60 keV gamma | Laborel box (ruined and sagregated for disposal) |- | 23 | Storage 4 #23 | ¹⁰⁹Cd | 1 | 37 | 1990 | 427 d | 88 keV gamma | Laborel box |- | 24 | Storage 4 #24 | ¹³⁹Ce | 1 | 37 | 1990 | 138 d | 166 keV gamma | Laborel box |- | 25 | Storage 4 #25 | ⁵⁷Co | 1 | 37 | 1990 | 272 d | 122 keV gamma | Laborel box |- | 26 | Storage 4 #26 | ¹³⁷Cs | 1 | 37 | 1990 | 30 y | 662 keV gamma | Laborel box |- | 27 | Storage 4 #27 | ⁵¹Cr | 1 | 37 | 1990 | 27 d | 320 keV gamma | Laborel box |- | 28 | Storage 4 #28 | ⁵⁴Mn | 1 | 37 | 1990 | 312 d | 835 keV gamma | Laborel box |- | 29 | Storage 4 #29 | ¹¹³Sn | 1 | 37 | 1990 | 115 d | 255 keV gamma | Laborel box |- | 30 | Storage 4 #30 | ⁸⁵Sr | 1 | 37 | 1990 | 65 d | 355 keV gamma | Laborel box |- | 31 | Storage 4 #31 | ⁶⁵Zn | 1 | 37 | 1990 | 244 d | 1 116 keV gamma | Laborel box |- | 32 | Storage 4 #32 | ¹³³Ba | 4 000 | 148 000 | 2014 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Eckert & Ziegler, Brass holder |- | 33 | Storage 4 #33 | ⁹⁰Sr | 54 | 2 010 | 1993 | 29 y | e^- | DESY |- | 34 | Storage 4 #34 | ⁵⁵Fe | 1 000 | 37 000 | 2014 | 2.7 y | X-rays | UiB# 0218698 |- | 35 | Storage 4 #35a | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- | 36 | Storage 4 #35b | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- |} ===Storage 3=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 3 #1 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 2 | Storage 3 #2 | ¹³³Ba | 1 | 37 | 2013 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | |- | 3 | Storage 3 #3 | ²²Na | 1 | 37 | 2013 | 2.6 y | 511, 1 275 keV gamma | |- | 4 | Storage 3 #4 | ⁵⁷Co | 1 | 37 | 2013 | 272 d | 122 keV gamma | |- | 5 | Storage 3 #5a | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 6 | Storage 3 #5b | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 7 | Storage 3 #6 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 3 #7 | ²⁴¹Am | 1 | 37 | 1976 | 458 y | Alpha + 60 keV gamma | Glass tube set |- | 9 | Storage 3 #8 | ⁹⁰Sr | 1 | 37 | 1976 | 29 y | e^- | Glass tube set |- | 10 | Storage 3 #9 | ⁵⁵Fe | 10 | 370 | 1976 | 30 y | 662 keV gamma | Glass tube set |- | 11 | Storage 3 #10 | ¹⁰⁶Ru | 2.7 | 100 | 2000 | 374 d | e^- | |- | 12 | Storage 3 #11 | ²⁴¹Am | 10 | 370 | 1975 | 458 y | Alpha + 60 keV gamma | ORTEC AM-1U, S/N M-1343, act. 0.088 |- | 13 | Storage 3 #12 | ⁹⁰Sr | 2 000 | 74 000 | 2022 | 29 y | e^- | VZ-3721-001 Capsule, Nominal |- |} ===Storage 2=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 2 #1a | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 2 | Storage 2 #1b | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 3 | Storage 2 #1c | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 4 | Storage 2 #1d | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 5 | Storage 2 #1e | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 6 | Storage 2 #1f | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 7 | Storage 2 #2 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 2 #3a | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 9 | Storage 2 #3b | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 10 | Storage 2 #4a | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 11 | Storage 2 #4b | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 12 | Storage 2 #5a | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 13 | Storage 2 #5b | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 14 | Storage 2 #6 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 15 | Storage 2 #7 | ¹⁵²Eu | 0.04 | 1.5 | 2006 | 13.5 y | Many gamma lines | Sealed Liquid |- | 16 | Storage 2 #8a | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 17 | Storage 2 #8b | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 18 | Storage 2 #8c | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 19 | Storage 2 #9a | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 20 | Storage 2 #9b | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 21 | Storage 2 #9c | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 22 | Storage 2 #9d | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 23 | Storage 2 #10 | ¹⁵²Eu | 1 | 37 | 2005 | 13.5 y | Many gamma lines | |- | 24 | Storage 2 #11a | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 25 | Storage 2 #11b | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 26 | Storage 2 #11c | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 27 | Storage 2 #11d | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 28 | Storage 2 #12a | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 29 | Storage 2 #12b | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 30 | Storage 2 #12c | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 31 | Storage 2 #13 | ²⁴¹Am | 0.24 | 9 | N/A | 458 y | 60 keV gamma | GDM 625 |- | 32 | Storage 2 #14 | ¹³⁷Cs | 1.22 | 45 | N/A | 30 y | 662 keV gamma | GDM 134 |- | 33 | Storage 2 #15 | UO₂ | N/A | N/A | N/A | N/A | N/A | Nuclear fuel pellet (black cylinder in epoxy cube) |- |} ===Storage 1=== ====White==== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 1W #1 | ²⁴¹Am | 10 000 | 370 000 | | 458 y | X-rays | Variable X-ray source |- | 2 | Storage 1W #2 | ²⁴¹Am | 10 | 370 | 1993 | 458 y | 60 keV gamma | DA289 written on the source |- | 3 | Storage 1W #3 | ⁶⁰Co | 10 | 370 | 1970 | 10.5 y | 1 173, 1 333 keV gamma | A943F |- | 4 | Storage 1W #4 | ¹⁴⁷Pm | 10 000 | 370 000 | 1974 | 2.6 y | 76, 198 keV gamma | A1124/N11958 |- | 5 | Storage 1W #5 | ¹³⁷Cs | 10 | 370 | | 30 y | 662 keV gamma | S/N 15319; A919F |- | 6 | Storage 1W #6 | ⁶⁰Co | 1 | 37 | | 10.5 y | 1 173, 1 333 keV gamma | S/N 811-L-1 |- | 7 | Storage 1W #7 | ²⁴¹Am | 0.1 | 3.7 | 1966 | 458 y | 60 keV gamma | A922F; S/N M954 Ortec |- | 8 | Storage 1W #8 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 9 | Storage 1W #9 | ¹³⁷Cs | 100 | 3 700 | 1984 | 30 y | 662 keV gamma | |- | 10 | Storage 1W #10 | ²⁴¹Am | 14 000 | 518 000 | 1984 | 458 y | 60 keV gamma | M55005 |- | 11 | Storage 1W #11 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 12 | Storage 1W #12 | ²²⁶Ra | 5-10 | 185-370 | 1970 | 1 600 y | 186 keV gamma | A859F; Leybold in a jar |- | 13 | Storage 1W #13 | ¹³⁷Cs | <10 | <370 | 2005 | 30 y | 662 keV gamma | Isotope generator |- | 14 | Storage 1W #14a | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 15 | Storage 1W #14b | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 16 | Storage 1W #14c | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 17 | Storage 1W #15 | ⁹⁰Sr | 2 000 | 74 000 | 1987 | 29 y | e^- | Amersham (in a blue cylindrical collimator) |- | 18 | Storage 1W #16 | | | | 1945 | | | Hiroshima dust |- | 19 | | | 0 | 0 | 2005 | | | Eluting solution for Tilf #13 Isotope generator |- |} ====Black==== {| class="wikitable" |- ! Item ! Source ID ! Activity, counts/s* ! Note |- | 1 | Storage 1B #1 | ~20 | Storage 1B R. 1 |- | 2 | Storage 1B #2 | ~120 | Storage 1B G. 1 |- | 3 | Storage 1B #3 | ~60 | Storage 1B G. 2 |- | 4 | Storage 1B #4 | ~100 | Storage 1B G. 3 |- | 5 | Storage 1B #5 | ~10 | Storage 1B G. 4 |- | 6 | Storage 1B #6 | ~10 | Storage 1B G. 5 |- | 7 | Storage 1B #7 | ~0 | Storage 1B G. 6 |- | 8 | Storage 1B #8 | ~220 | Storage 1B G. 7 |- | 9 | Storage 1B #9 | ~150 | Storage 1B G. 8 |- | 10 | Storage 1B #10 | ~10 | Storage 1B G. 9 |- | 11 | Storage 1B #11 | ~350 | Storage 1B G. 10 |- | 12 | Storage 1B #12 | ~500 | Storage 1B G. 11 |- | 13 | Storage 1B #13 | ~1 000 | Storage 1B G. 12 |- |} <nowiki>*</nowiki>Activity measured with an 1" NaI(Tl) crystal 79247abfc3a94910c9f25ee028d3a2af250d2fa1 2893 2892 2022-11-25T14:53:55Z Sya081 50 /* Storage 3 */ wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. ==List of sealed sources at the IFT== ===Storage 4=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 4 #1 | ²⁴¹Am | 27 | 1 000 | 2006 | 458 y | 60 keV gamma | OI428/Code: AMRB 13788 |- | 2 | Storage 4 #2 | ⁵⁷Co | 100 | 3 700 | 2006 | 272 d | 122 keV gamma | Code: CTR 8252 |- | 3 | Storage 4 #3 | ¹³³Ba | 100 | 3 700 | 2006 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Code: BDR 8252 |- | 4 | Storage 4 #4 | ¹⁵⁵Eu | 100 | 3 700 | 1993 | 4.8 y | 105 keV gamma | |- | 5 | Storage 4 #5 | ²²⁶Ra | 2.7 | 100 | ~1970 | 1 600 y | 186 keV gamma | |- | 6 | Storage 4 #6 | ¹³⁷Cs | 60 | 2 200 | 1986 | 30 y | 662 keV gamma | |- | 7 | Storage 4 #7 | ²⁴¹Am | 3 000 | 100 000 | 1977 | 458 y | 60 keV gamma | UB/FIB 539 |- | 8 | Storage 4 #8 | ²⁴¹Am | 10 000 | 370 000 | 1987 | 458 y | | Variable X-ray source |- | 9 | Storage 4 #9 | ⁵⁵Fe | 20 000 | 740 000 | N/A | 2.7 y | X-rays | Decayed |- | 10 | Storage 4 #10 | ¹⁰⁹Cd | 1 | 37 | 2011 | 427 d | 88 keV gamma | Calibr. Set Spectrum Techniques |- | 11 | Storage 4 #11 | ⁵⁷Co | 1 | 37 | 2011 | 272 d | 122 keV gamma | Calibr. Set Spectrum Techniques |- | 12 | Storage 4 #12 | ¹³³Ba | 1 | 37 | 2011 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. Set Spectrum Techniques |- | 13 | Storage 4 #13 | ⁶⁰Co | 1 | 37 | 2011 | 5.3 y | 1 173, 1 333 keV gamma | Calibr. Set Spectrum Techniques |- | 14 | Storage 4 #14 | ¹³⁷Cs | 1 | 37 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 15 | Storage 4 #15 | ²²Na | 1 | 37 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 16 | Storage 4 #16 | ¹³⁷Cs⁶⁵Zn | 1 | 37 | 2011 | 30 y + 244 d | 662 + 1 116 keV gamma | Calibr. Set Spectrum Techniques |- | 17 | Storage 4 #17 | ⁵⁴Mn | 1 | 37 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 18 | Storage 4 #18 | ¹³⁷Cs | 10 | 370 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 19 | Storage 4 #19 | ²²Na | 10 | 370 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 20 | Storage 4 #20 | ⁵⁴Mn | 10 | 370 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 21 | Storage 4 #21 | ¹³³Ba | 10 | 370 | 2012 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. source Eckert & Ziegler |- | 22 | Storage 4 #22 | ²⁴¹Am | 1 | 37 | 1990 | 458 y | 60 keV gamma | Laborel box (ruined and sagregated for disposal) |- | 23 | Storage 4 #23 | ¹⁰⁹Cd | 1 | 37 | 1990 | 427 d | 88 keV gamma | Laborel box |- | 24 | Storage 4 #24 | ¹³⁹Ce | 1 | 37 | 1990 | 138 d | 166 keV gamma | Laborel box |- | 25 | Storage 4 #25 | ⁵⁷Co | 1 | 37 | 1990 | 272 d | 122 keV gamma | Laborel box |- | 26 | Storage 4 #26 | ¹³⁷Cs | 1 | 37 | 1990 | 30 y | 662 keV gamma | Laborel box |- | 27 | Storage 4 #27 | ⁵¹Cr | 1 | 37 | 1990 | 27 d | 320 keV gamma | Laborel box |- | 28 | Storage 4 #28 | ⁵⁴Mn | 1 | 37 | 1990 | 312 d | 835 keV gamma | Laborel box |- | 29 | Storage 4 #29 | ¹¹³Sn | 1 | 37 | 1990 | 115 d | 255 keV gamma | Laborel box |- | 30 | Storage 4 #30 | ⁸⁵Sr | 1 | 37 | 1990 | 65 d | 355 keV gamma | Laborel box |- | 31 | Storage 4 #31 | ⁶⁵Zn | 1 | 37 | 1990 | 244 d | 1 116 keV gamma | Laborel box |- | 32 | Storage 4 #32 | ¹³³Ba | 4 000 | 148 000 | 2014 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Eckert & Ziegler, Brass holder |- | 33 | Storage 4 #33 | ⁹⁰Sr | 54 | 2 010 | 1993 | 29 y | e^- | DESY |- | 34 | Storage 4 #34 | ⁵⁵Fe | 1 000 | 37 000 | 2014 | 2.7 y | X-rays | UiB# 0218698 |- | 35 | Storage 4 #35a | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- | 36 | Storage 4 #35b | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- |} ===Storage 3=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 3 #1 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 2 | Storage 3 #2 | ¹³³Ba | 1 | 37 | 2013 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | |- | 3 | Storage 3 #3 | ²²Na | 1 | 37 | 2013 | 2.6 y | 511, 1 275 keV gamma | |- | 4 | Storage 3 #4 | ⁵⁷Co | 1 | 37 | 2013 | 272 d | 122 keV gamma | |- | 5 | Storage 3 #5a | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 6 | Storage 3 #5b | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 7 | Storage 3 #6 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 3 #7 | ²⁴¹Am | 1 | 37 | 1976 | 458 y | Alpha + 60 keV gamma | Glass tube set |- | 9 | Storage 3 #8 | ⁹⁰Sr | 1 | 37 | 1976 | 29 y | e^- | Glass tube set |- | 10 | Storage 3 #9 | ⁵⁵Fe | 10 | 370 | 1976 | 30 y | 662 keV gamma | Glass tube set |- | 11 | Storage 3 #10 | ¹⁰⁶Ru | 2.7 | 100 | 2000 | 374 d | e^- | |- | 12 | Storage 3 #11 | ²⁴¹Am | 10 | 370 | 1975 | 458 y | Alpha + 60 keV gamma | ORTEC AM-1U, S/N M-1343, act. 0.088 |- | 13 | Storage 3 #12 | ⁹⁰Sr | 2 000 | 74 000 | 2022 | 29 y | e^- | VZ-3721-001 Capsule, Nominal, Φ 8mm x 5mm |- |} ===Storage 2=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 2 #1a | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 2 | Storage 2 #1b | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 3 | Storage 2 #1c | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 4 | Storage 2 #1d | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 5 | Storage 2 #1e | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 6 | Storage 2 #1f | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 7 | Storage 2 #2 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 2 #3a | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 9 | Storage 2 #3b | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 10 | Storage 2 #4a | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 11 | Storage 2 #4b | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 12 | Storage 2 #5a | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 13 | Storage 2 #5b | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 14 | Storage 2 #6 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 15 | Storage 2 #7 | ¹⁵²Eu | 0.04 | 1.5 | 2006 | 13.5 y | Many gamma lines | Sealed Liquid |- | 16 | Storage 2 #8a | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 17 | Storage 2 #8b | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 18 | Storage 2 #8c | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 19 | Storage 2 #9a | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 20 | Storage 2 #9b | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 21 | Storage 2 #9c | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 22 | Storage 2 #9d | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 23 | Storage 2 #10 | ¹⁵²Eu | 1 | 37 | 2005 | 13.5 y | Many gamma lines | |- | 24 | Storage 2 #11a | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 25 | Storage 2 #11b | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 26 | Storage 2 #11c | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 27 | Storage 2 #11d | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 28 | Storage 2 #12a | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 29 | Storage 2 #12b | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 30 | Storage 2 #12c | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 31 | Storage 2 #13 | ²⁴¹Am | 0.24 | 9 | N/A | 458 y | 60 keV gamma | GDM 625 |- | 32 | Storage 2 #14 | ¹³⁷Cs | 1.22 | 45 | N/A | 30 y | 662 keV gamma | GDM 134 |- | 33 | Storage 2 #15 | UO₂ | N/A | N/A | N/A | N/A | N/A | Nuclear fuel pellet (black cylinder in epoxy cube) |- |} ===Storage 1=== ====White==== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 1W #1 | ²⁴¹Am | 10 000 | 370 000 | | 458 y | X-rays | Variable X-ray source |- | 2 | Storage 1W #2 | ²⁴¹Am | 10 | 370 | 1993 | 458 y | 60 keV gamma | DA289 written on the source |- | 3 | Storage 1W #3 | ⁶⁰Co | 10 | 370 | 1970 | 10.5 y | 1 173, 1 333 keV gamma | A943F |- | 4 | Storage 1W #4 | ¹⁴⁷Pm | 10 000 | 370 000 | 1974 | 2.6 y | 76, 198 keV gamma | A1124/N11958 |- | 5 | Storage 1W #5 | ¹³⁷Cs | 10 | 370 | | 30 y | 662 keV gamma | S/N 15319; A919F |- | 6 | Storage 1W #6 | ⁶⁰Co | 1 | 37 | | 10.5 y | 1 173, 1 333 keV gamma | S/N 811-L-1 |- | 7 | Storage 1W #7 | ²⁴¹Am | 0.1 | 3.7 | 1966 | 458 y | 60 keV gamma | A922F; S/N M954 Ortec |- | 8 | Storage 1W #8 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 9 | Storage 1W #9 | ¹³⁷Cs | 100 | 3 700 | 1984 | 30 y | 662 keV gamma | |- | 10 | Storage 1W #10 | ²⁴¹Am | 14 000 | 518 000 | 1984 | 458 y | 60 keV gamma | M55005 |- | 11 | Storage 1W #11 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 12 | Storage 1W #12 | ²²⁶Ra | 5-10 | 185-370 | 1970 | 1 600 y | 186 keV gamma | A859F; Leybold in a jar |- | 13 | Storage 1W #13 | ¹³⁷Cs | <10 | <370 | 2005 | 30 y | 662 keV gamma | Isotope generator |- | 14 | Storage 1W #14a | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 15 | Storage 1W #14b | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 16 | Storage 1W #14c | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 17 | Storage 1W #15 | ⁹⁰Sr | 2 000 | 74 000 | 1987 | 29 y | e^- | Amersham (in a blue cylindrical collimator) |- | 18 | Storage 1W #16 | | | | 1945 | | | Hiroshima dust |- | 19 | | | 0 | 0 | 2005 | | | Eluting solution for Tilf #13 Isotope generator |- |} ====Black==== {| class="wikitable" |- ! Item ! Source ID ! Activity, counts/s* ! Note |- | 1 | Storage 1B #1 | ~20 | Storage 1B R. 1 |- | 2 | Storage 1B #2 | ~120 | Storage 1B G. 1 |- | 3 | Storage 1B #3 | ~60 | Storage 1B G. 2 |- | 4 | Storage 1B #4 | ~100 | Storage 1B G. 3 |- | 5 | Storage 1B #5 | ~10 | Storage 1B G. 4 |- | 6 | Storage 1B #6 | ~10 | Storage 1B G. 5 |- | 7 | Storage 1B #7 | ~0 | Storage 1B G. 6 |- | 8 | Storage 1B #8 | ~220 | Storage 1B G. 7 |- | 9 | Storage 1B #9 | ~150 | Storage 1B G. 8 |- | 10 | Storage 1B #10 | ~10 | Storage 1B G. 9 |- | 11 | Storage 1B #11 | ~350 | Storage 1B G. 10 |- | 12 | Storage 1B #12 | ~500 | Storage 1B G. 11 |- | 13 | Storage 1B #13 | ~1 000 | Storage 1B G. 12 |- |} <nowiki>*</nowiki>Activity measured with an 1" NaI(Tl) crystal 8994bd9c5e711960270330a33f52e0fdee271e73 2899 2893 2023-12-15T14:04:06Z Sya081 50 wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. ==List of sealed sources at the IFT== ===Storage 4=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 4 #1 | ²⁴¹Am | 27 | 1 000 | 2006 | 458 y | 60 keV gamma | OI428/Code: AMRB 13788 |- | 2 | Storage 4 #2 | ⁵⁷Co | 100 | 3 700 | 2006 | 272 d | 122 keV gamma | Code: CTR 8252 |- | 3 | Storage 4 #3 | ¹³³Ba | 100 | 3 700 | 2006 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Code: BDR 8252 |- | 4 | Storage 4 #4 | ¹⁵⁵Eu | 100 | 3 700 | 1993 | 4.8 y | 105 keV gamma | |- | 5 | | | | | | | | |- | 6 | Storage 4 #6 | ¹³⁷Cs | 60 | 2 200 | 1986 | 30 y | 662 keV gamma | |- | 7 | Storage 4 #7 | ²⁴¹Am | 3 000 | 100 000 | 1977 | 458 y | 60 keV gamma | UB/FIB 539 |- | 8 | Storage 4 #8 | ²⁴¹Am | 10 000 | 370 000 | 1987 | 458 y | | Variable X-ray source |- | 9 | Storage 4 #9 | ⁵⁵Fe | 20 000 | 740 000 | N/A | 2.7 y | X-rays | Decayed |- | 10 | Storage 4 #10 | ¹⁰⁹Cd | 1 | 37 | 2011 | 427 d | 88 keV gamma | Calibr. Set Spectrum Techniques |- | 11 | Storage 4 #11 | ⁵⁷Co | 1 | 37 | 2011 | 272 d | 122 keV gamma | Calibr. Set Spectrum Techniques |- | 12 | Storage 4 #12 | ¹³³Ba | 1 | 37 | 2011 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. Set Spectrum Techniques |- | 13 | Storage 4 #13 | ⁶⁰Co | 1 | 37 | 2011 | 5.3 y | 1 173, 1 333 keV gamma | Calibr. Set Spectrum Techniques |- | 14 | Storage 4 #14 | ¹³⁷Cs | 1 | 37 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 15 | Storage 4 #15 | ²²Na | 1 | 37 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 16 | Storage 4 #16 | ¹³⁷Cs⁶⁵Zn | 1 | 37 | 2011 | 30 y + 244 d | 662 + 1 116 keV gamma | Calibr. Set Spectrum Techniques |- | 17 | Storage 4 #17 | ⁵⁴Mn | 1 | 37 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 18 | Storage 4 #18 | ¹³⁷Cs | 10 | 370 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 19 | Storage 4 #19 | ²²Na | 10 | 370 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 20 | Storage 4 #20 | ⁵⁴Mn | 10 | 370 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 21 | Storage 4 #21 | ¹³³Ba | 10 | 370 | 2012 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. source Eckert & Ziegler |- | 22 | Storage 4 #22 | ²⁴¹Am | 1 | 37 | 1990 | 458 y | 60 keV gamma | Laborel box (ruined and sagregated for disposal) |- | 23 | Storage 4 #23 | ¹⁰⁹Cd | 1 | 37 | 1990 | 427 d | 88 keV gamma | Laborel box |- | 24 | Storage 4 #24 | ¹³⁹Ce | 1 | 37 | 1990 | 138 d | 166 keV gamma | Laborel box |- | 25 | Storage 4 #25 | ⁵⁷Co | 1 | 37 | 1990 | 272 d | 122 keV gamma | Laborel box |- | 26 | Storage 4 #26 | ¹³⁷Cs | 1 | 37 | 1990 | 30 y | 662 keV gamma | Laborel box |- | 27 | Storage 4 #27 | ⁵¹Cr | 1 | 37 | 1990 | 27 d | 320 keV gamma | Laborel box |- | 28 | Storage 4 #28 | ⁵⁴Mn | 1 | 37 | 1990 | 312 d | 835 keV gamma | Laborel box |- | 29 | Storage 4 #29 | ¹¹³Sn | 1 | 37 | 1990 | 115 d | 255 keV gamma | Laborel box |- | 30 | Storage 4 #30 | ⁸⁵Sr | 1 | 37 | 1990 | 65 d | 355 keV gamma | Laborel box |- | 31 | Storage 4 #31 | ⁶⁵Zn | 1 | 37 | 1990 | 244 d | 1 116 keV gamma | Laborel box |- | 32 | Storage 4 #32 | ¹³³Ba | 4 000 | 148 000 | 2014 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Eckert & Ziegler, Brass holder |- | 33 | Storage 4 #33 | ⁹⁰Sr | 54 | 2 010 | 1993 | 29 y | e^- | DESY |- | 34 | Storage 4 #34 | ⁵⁵Fe | 1 000 | 37 000 | 2014 | 2.7 y | X-rays | UiB# 0218698 |- | 35 | Storage 4 #35a | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- | 36 | Storage 4 #35b | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- |} ===Storage 3=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 3 #1 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 2 | Storage 3 #2 | ¹³³Ba | 1 | 37 | 2013 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | |- | 3 | Storage 3 #3 | ²²Na | 1 | 37 | 2013 | 2.6 y | 511, 1 275 keV gamma | |- | 4 | Storage 3 #4 | ⁵⁷Co | 1 | 37 | 2013 | 272 d | 122 keV gamma | |- | 5 | Storage 3 #5a | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 6 | Storage 3 #5b | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 7 | Storage 3 #6 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 3 #7 | ²⁴¹Am | 1 | 37 | 1976 | 458 y | Alpha + 60 keV gamma | Glass tube set |- | 9 | Storage 3 #8 | ⁹⁰Sr | 1 | 37 | 1976 | 29 y | e^- | Glass tube set |- | 10 | Storage 3 #9 | ⁵⁵Fe | 10 | 370 | 1976 | 30 y | 662 keV gamma | Glass tube set |- | 11 | Storage 3 #10 | ¹⁰⁶Ru | 2.7 | 100 | 2000 | 374 d | e^- | |- | 12 | Storage 3 #11 | ²⁴¹Am | 10 | 370 | 1975 | 458 y | Alpha + 60 keV gamma | ORTEC AM-1U, S/N M-1343, act. 0.088 |- | 13 | Storage 3 #12 | ⁹⁰Sr | 2 000 | 74 000 | 2022 | 29 y | e^- | VZ-3721-001 Capsule, Nominal, Φ 8mm x 5mm |- |} ===Storage 2=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 2 #1a | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 2 | Storage 2 #1b | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 3 | Storage 2 #1c | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 4 | Storage 2 #1d | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 5 | Storage 2 #1e | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 6 | Storage 2 #1f | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 7 | Storage 2 #2 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 2 #3a | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 9 | Storage 2 #3b | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 10 | Storage 2 #4a | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 11 | Storage 2 #4b | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 12 | Storage 2 #5a | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 13 | Storage 2 #5b | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 14 | Storage 2 #6 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 15 | Storage 2 #7 | ¹⁵²Eu | 0.04 | 1.5 | 2006 | 13.5 y | Many gamma lines | Sealed Liquid |- | 16 | Storage 2 #8a | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 17 | Storage 2 #8b | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 18 | Storage 2 #8c | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 19 | Storage 2 #9a | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 20 | Storage 2 #9b | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 21 | Storage 2 #9c | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 22 | Storage 2 #9d | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 23 | Storage 2 #10 | ¹⁵²Eu | 1 | 37 | 2005 | 13.5 y | Many gamma lines | |- | 24 | Storage 2 #11a | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 25 | Storage 2 #11b | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 26 | Storage 2 #11c | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 27 | Storage 2 #11d | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 28 | Storage 2 #12a | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 29 | Storage 2 #12b | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 30 | Storage 2 #12c | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 31 | Storage 2 #13 | ²⁴¹Am | 0.24 | 9 | N/A | 458 y | 60 keV gamma | GDM 625 |- | 32 | Storage 2 #14 | ¹³⁷Cs | 1.22 | 45 | N/A | 30 y | 662 keV gamma | GDM 134 |- | 33 | Storage 2 #15 | UO₂ | N/A | N/A | N/A | N/A | N/A | Nuclear fuel pellet (black cylinder in epoxy cube) |- |} ===Storage 1=== ====White==== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 1W #1 | ²⁴¹Am | 10 000 | 370 000 | | 458 y | X-rays | Variable X-ray source |- | 2 | Storage 1W #2 | ²⁴¹Am | 10 | 370 | 1993 | 458 y | 60 keV gamma | DA289 written on the source |- | 3 | Storage 1W #3 | ⁶⁰Co | 10 | 370 | 1970 | 10.5 y | 1 173, 1 333 keV gamma | A943F |- | 4 | Storage 1W #4 | ¹⁴⁷Pm | 10 000 | 370 000 | 1974 | 2.6 y | 76, 198 keV gamma | A1124/N11958 |- | 5 | Storage 1W #5 | ¹³⁷Cs | 10 | 370 | | 30 y | 662 keV gamma | S/N 15319; A919F |- | 6 | Storage 1W #6 | ⁶⁰Co | 1 | 37 | | 10.5 y | 1 173, 1 333 keV gamma | S/N 811-L-1 |- | 7 | Storage 1W #7 | ²⁴¹Am | 0.1 | 3.7 | 1966 | 458 y | 60 keV gamma | A922F; S/N M954 Ortec |- | 8 | Storage 1W #8 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 9 | Storage 1W #9 | ¹³⁷Cs | 100 | 3 700 | 1984 | 30 y | 662 keV gamma | |- | 10 | Storage 1W #10 | ²⁴¹Am | 14 000 | 518 000 | 1984 | 458 y | 60 keV gamma | M55005 |- | 11 | Storage 1W #11 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 12 | Storage 1W #12 | ²²⁶Ra | 5-10 | 185-370 | 1970 | 1 600 y | 186 keV gamma | A859F; Leybold in a jar |- | 13 | Storage 1W #13 | ¹³⁷Cs | <10 | <370 | 2005 | 30 y | 662 keV gamma | Isotope generator |- | 14 | Storage 1W #14a | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 15 | Storage 1W #14b | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 16 | Storage 1W #14c | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 17 | Storage 1W #15 | ⁹⁰Sr | 2 000 | 74 000 | 1987 | 29 y | e^- | Amersham (in a blue cylindrical collimator) |- | 18 | Storage 1W #16 | | | | 1945 | | | Hiroshima dust |- | 19 | | | 0 | 0 | 2005 | | | Eluting solution for Tilf #13 Isotope generator |- | 20 | Storage 4 #5 | ²²⁶Ra | 2.7 | 100 | ~1970 | 1 600 y | 186 keV gamma | Previously store in Lab 420 |- |} ====Black==== {| class="wikitable" |- ! Item ! Source ID ! Activity, counts/s* ! Note |- | 1 | Storage 1B #1 | ~20 | Storage 1B R. 1 |- | 2 | Storage 1B #2 | ~120 | Storage 1B G. 1 |- | 3 | Storage 1B #3 | ~60 | Storage 1B G. 2 |- | 4 | Storage 1B #4 | ~100 | Storage 1B G. 3 |- | 5 | Storage 1B #5 | ~10 | Storage 1B G. 4 |- | 6 | Storage 1B #6 | ~10 | Storage 1B G. 5 |- | 7 | Storage 1B #7 | ~0 | Storage 1B G. 6 |- | 8 | Storage 1B #8 | ~220 | Storage 1B G. 7 |- | 9 | Storage 1B #9 | ~150 | Storage 1B G. 8 |- | 10 | Storage 1B #10 | ~10 | Storage 1B G. 9 |- | 11 | Storage 1B #11 | ~350 | Storage 1B G. 10 |- | 12 | Storage 1B #12 | ~500 | Storage 1B G. 11 |- | 13 | Storage 1B #13 | ~1 000 | Storage 1B G. 12 |- |} <nowiki>*</nowiki>Activity measured with an 1" NaI(Tl) crystal d9dd214792b39ad99f39d15baa89b5ed0ee03f24 2900 2899 2023-12-15T14:04:56Z Sya081 50 wikitext text/x-wiki ==Førstegangsbrukere / First-time users== ===Norsk=== Førstegangsbrukere skal: #Ta kontakt med strålevernkoordinator (STK) #Få de nødvendige instruksene fra STK om interne regler for bruk av strålekilder #Bli registrert for å få personlig dosimeter #Vente på dosimeteret (tar ca. 1-2 uker) #Begynne å bruke kilder etter de har fått sitt personlige dosimeter #Returnere dosimeteret sitt hvis det ikke trengs lenger (gravide brukere skal ikke jobbe med strålingskilder i løpet av svangerskapet) ===English=== First-time users shall: #Contact the Radiation protection responsible (RPR) #Receive the required instructions from the RPR on internal regulations for use of radioactive sources #Be registered for obtaining a personal dosimeter #Wait for the dosimeter (takes 1-2 weeks) #Begin working with sources after having received her/his personal dosimeter #Return her/his personal dosimeter if it is no longer needed (pregnant women shall not work with ionizing radiation during the pregnancy) ==Regler for bruk av strålekilder på IFT / Regulations for use of radioactive sources at the IFT== ===Norsk=== [[File:hierarket.jpg|thumb|alt=Hierarke / Hierarchy |Fig. 1 Hierarke / Hierarchy ]] [[File:TableHeader.jpg|thumb|alt=Logbokformat / Logbook format|Fig. 2 Logbokformat / Logbook format]] [[File:Slide2.JPG|thumb|alt=Logbokformat|Fig. 3 Skilt som brukes til svake kilder / Sign used for designating an area where weak sources are used]] [[File:Slide1.JPG|thumb|alt=Logbokformat|Fig. 4 Skilt som brukes til sterke kilder og kontaminerte områder hvor begrenset opphold er bare tillatt / Sign used for designating an area where strong sources are used, or for contaminated areas, where only a limited time presence is allowed]] #Strålevernkoordinatoren (STK) har oversikt over alle kildenes status. #Ansvarshierarkiet er som vist i Fig. 1. #Hver lab bør ha lab kildeansvarlig. I tilfelle det ikke er lab-kildeansvarlig deles kildene ut av STK. #Lab-kildeansvarlig velges av lab-brukerne, STK eller instituttleder. #Hver lab skal ha loggbok hvor bevegelsene til hver kilde som hører til denne laben skal registreres. Loggboken skal ha formatet som vist i Fig. 2: #Den første siden i loggboken skal ha navn og kontaktinfo til lab kildeansvarlig og navn og kontakt info til STK. #Loggboken skal være på labben til enhver tid, bundet med snor til kildeskapet. #Det er lab kildeansvarlig sitt ansvar å føre boken riktig. #STK skal kontrollere jobben til lab-kildeansvarlig ofte og uten varsel. #Det er 1 nøkkel til tilsvarende kildeskap hos lab-kildeansvarlig og 1 nøkkel hos STK. Leder for teknisk Avdeling (TA) og 1 ingeniør fra TA skal kunne få tilgang til STK sine nøkler i tilfelle STK ikke er tilstede. #Alle personer som har tilgang til nøkler til kildeskap får opplæring i dette regelverket og generell strålevern fra STK. #Ingen av ovennevnte får lov til å låne sin nøkkel til noen. STK kan delegere ansvaret for nøklene sine, men overføringen skal skje med overtagelsesprotokoll som er en del av loggboken. Lab-kildeansvarlig kan IKKE delegere sitt ansvar for nøkkelen. #En kildebruker skal først ta kontakt med sin lab-kildeansvarlig. Hvis han/hun ikke er tilstede kontaktes STK. Hvis han/hun ikke er til stedet kontaktes leder TA. Hvis han/hun ikke er til stedet kontaktes ingeniøren som er ansvarlig. Det er IKKE lov å hoppe over noen. #Hvis lab kildeansvarlig sier opp blir det varetelling med STK og instituttleder og signering av overtagelsesprotokoll. #Hvis STK sier opp blir det varetelling med UiB STK, instituttleder og den nye STK. Overtagelsesprotokoll signeres. #Arbeidsplass med åpen strålekilde skal merkeres med skilt (Fig. 3 eller Fig. 4) og eksponeringsvurdering skal utføres om nødvendig. #Det er ikke ønskelig å la kilder stå uovervåket. Hvis dette er nødvendig skal arbeidstedet markeres. #Det er ikke lov å jobbe med strålekilder uten dosimeter. STK og HMS-ansvarlig skal kontrollere labbene og brukerne uten varsel. #Hver bruker skal ha innføring i strålevern fra STK før de begynner å jobbe med kilder. Studenter som har bestått PHYS231 Strålingsfysikk får fritak. #Gravide brukere skal returnere sine dosimetere til HMS-ansvarlige i det øyeblikket de finner ut at de er gravide (se punkt 18). Dosimeteret blir returnert etter fødsel om det fremdeles er ønskelig. #Brukere som ikke har bruk for dosimeter lenger skal returnere dem til HMS ansvarlig. #Dosimetrene skal oppbevares på samme sted når de ikke er i bruk. Det stede skal bestemmes mellom bruker, STK og personen som er ansvarlig for den periodiske skift av TLD. #De personlige dosimetrene skal brukes bare på IFT og skal ikke taes fra huset. Dette inkluderer ansatte som jobber på eksterne fasiliteter som f.eks. CERN. Sånne ansatte får dosimetrer fra fasilitetene de besøker. ===English=== #The Radiation protection responsible (RPR) has all the information on the status of the radioactive sources at the IFT. #The hierarchy and the responsibilities are defined in Fig. 1. #Every lab should have a responsible for the radioactive sources. During the absence of the lab responsible it is the RPR who gives out sources. #The lab responsible is elected by the users in that lab, RPR or the Head of the department. #Every lab will have a logbook where the movement of all the sources belonging to this lab will be registered. The format of the logbook will be as shown in Fig. 2. #The first page in the logbook will contain the name and the contact info of the lab responsible and the name and the contact info of the RPR. #The logbook will be in the lab at all times, bound to the safe with the sources with the help of a thread. #It is the responsibility of the lab responsible to keep the book correctly. #RPR shall inspect the work of the lab responsible often and without warning. #There is one key per safe in the possession of the lab responsible and one key with the RPR. Head of Technical department and one engineer shall be able to access to the keys belonging to the RPR in case the RPR is absent. #All persons who have access to keys for the safes with radioactive sources shall be briefed on this framework of rules and on general radiation protection by the RPR. #Nobody from the aforementioned personnel is allowed to lend their keys to anyone. RPR can delegate the responsibility for a certain safe, but this will happen with a protocol. The protocol is a part of the logbook. The lab responsible is not allowed to delegate her/his responsibilities. #The users will first contact their lab responsible. If she/he are not present, the RPR is to be contacted. If she/he is not present the Head of the Technical department is to be contacted. If she/he is not present the authorized engineer is to be contacted. #When the lab responsible quits there will be an inspection of the inventory with the RPR and the Head of the Department, followed by signing a transfer protocol. #When the RPR quits there will be an inventory inspection together with the UiB RPR, the Head of the Department and the new RPR. This will result in signing a transfer protocol. #Workplace with an open radioactive source will be marked with a shield (Fig. 3 or Fig. 4) and there shall be a dose estimate if needed. #It is undesirable to leave sources unattended. If this is necessary, the work place shall be marked accordingly. #It is forbidden to work with radioactive sources without a dosimeter. The RPR and HSE responsible will the labs and the users without warning. #Every new user shall receive an introduction in radiation protection by the RPR before beginning to work with radioactive sources. Students who have successfully passed PHYS231 Strålingsfysikk or equivalent are exempt. #Pregnant users shall return their dosimeters to the HSE responsible in the moment they discover they are pregnant (see item 18). The dosimeters shall be returned after birth if they are still needed. #Users who no longer need their dosimeters shall return them to the HSE responsible. #The dosimeters shall be stored in the same place whenever they are no in use. That place is agreed upon between the user, the RPR and the person responsible for the periodic change of the TLD. #The personal dosimeter shall be used only when working at the IFT and shall be located at the IFT building at all times. This includes students and employees who work at external organizations like CERN. Such employees and students receive dosimeters at the institutions they visit. ==List of sealed sources at the IFT== ===Storage 4=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 4 #1 | ²⁴¹Am | 27 | 1 000 | 2006 | 458 y | 60 keV gamma | OI428/Code: AMRB 13788 |- | 2 | Storage 4 #2 | ⁵⁷Co | 100 | 3 700 | 2006 | 272 d | 122 keV gamma | Code: CTR 8252 |- | 3 | Storage 4 #3 | ¹³³Ba | 100 | 3 700 | 2006 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Code: BDR 8252 |- | 4 | Storage 4 #4 | ¹⁵⁵Eu | 100 | 3 700 | 1993 | 4.8 y | 105 keV gamma | |- | 5 | | | | | | | | |- | 6 | Storage 4 #6 | ¹³⁷Cs | 60 | 2 200 | 1986 | 30 y | 662 keV gamma | |- | 7 | Storage 4 #7 | ²⁴¹Am | 3 000 | 100 000 | 1977 | 458 y | 60 keV gamma | UB/FIB 539 |- | 8 | Storage 4 #8 | ²⁴¹Am | 10 000 | 370 000 | 1987 | 458 y | | Variable X-ray source |- | 9 | Storage 4 #9 | ⁵⁵Fe | 20 000 | 740 000 | N/A | 2.7 y | X-rays | Decayed |- | 10 | Storage 4 #10 | ¹⁰⁹Cd | 1 | 37 | 2011 | 427 d | 88 keV gamma | Calibr. Set Spectrum Techniques |- | 11 | Storage 4 #11 | ⁵⁷Co | 1 | 37 | 2011 | 272 d | 122 keV gamma | Calibr. Set Spectrum Techniques |- | 12 | Storage 4 #12 | ¹³³Ba | 1 | 37 | 2011 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. Set Spectrum Techniques |- | 13 | Storage 4 #13 | ⁶⁰Co | 1 | 37 | 2011 | 5.3 y | 1 173, 1 333 keV gamma | Calibr. Set Spectrum Techniques |- | 14 | Storage 4 #14 | ¹³⁷Cs | 1 | 37 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 15 | Storage 4 #15 | ²²Na | 1 | 37 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 16 | Storage 4 #16 | ¹³⁷Cs⁶⁵Zn | 1 | 37 | 2011 | 30 y + 244 d | 662 + 1 116 keV gamma | Calibr. Set Spectrum Techniques |- | 17 | Storage 4 #17 | ⁵⁴Mn | 1 | 37 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 18 | Storage 4 #18 | ¹³⁷Cs | 10 | 370 | 2011 | 30 y | 662 keV gamma | Calibr. Set Spectrum Techniques |- | 19 | Storage 4 #19 | ²²Na | 10 | 370 | 2011 | 2.6 y | 511, 1 275 keV gamma | Calibr. Set Spectrum Techniques |- | 20 | Storage 4 #20 | ⁵⁴Mn | 10 | 370 | 2011 | 312 d | 835 keV gamma | Calibr. Set Spectrum Techniques |- | 21 | Storage 4 #21 | ¹³³Ba | 10 | 370 | 2012 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Calibr. source Eckert & Ziegler |- | 22 | Storage 4 #22 | ²⁴¹Am | 1 | 37 | 1990 | 458 y | 60 keV gamma | Laborel box (ruined and sagregated for disposal) |- | 23 | Storage 4 #23 | ¹⁰⁹Cd | 1 | 37 | 1990 | 427 d | 88 keV gamma | Laborel box |- | 24 | Storage 4 #24 | ¹³⁹Ce | 1 | 37 | 1990 | 138 d | 166 keV gamma | Laborel box |- | 25 | Storage 4 #25 | ⁵⁷Co | 1 | 37 | 1990 | 272 d | 122 keV gamma | Laborel box |- | 26 | Storage 4 #26 | ¹³⁷Cs | 1 | 37 | 1990 | 30 y | 662 keV gamma | Laborel box |- | 27 | Storage 4 #27 | ⁵¹Cr | 1 | 37 | 1990 | 27 d | 320 keV gamma | Laborel box |- | 28 | Storage 4 #28 | ⁵⁴Mn | 1 | 37 | 1990 | 312 d | 835 keV gamma | Laborel box |- | 29 | Storage 4 #29 | ¹¹³Sn | 1 | 37 | 1990 | 115 d | 255 keV gamma | Laborel box |- | 30 | Storage 4 #30 | ⁸⁵Sr | 1 | 37 | 1990 | 65 d | 355 keV gamma | Laborel box |- | 31 | Storage 4 #31 | ⁶⁵Zn | 1 | 37 | 1990 | 244 d | 1 116 keV gamma | Laborel box |- | 32 | Storage 4 #32 | ¹³³Ba | 4 000 | 148 000 | 2014 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | Eckert & Ziegler, Brass holder |- | 33 | Storage 4 #33 | ⁹⁰Sr | 54 | 2 010 | 1993 | 29 y | e^- | DESY |- | 34 | Storage 4 #34 | ⁵⁵Fe | 1 000 | 37 000 | 2014 | 2.7 y | X-rays | UiB# 0218698 |- | 35 | Storage 4 #35a | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- | 36 | Storage 4 #35b | ¹⁴C | 10 | 370 | 2018 | 5730 y | e^- | Thin plate; Spec. Tech. Mod# C14LMW10 |- |} ===Storage 3=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 3 #1 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 2 | Storage 3 #2 | ¹³³Ba | 1 | 37 | 2013 | 10.5 y | 80, 276, 303, 356, 384 keV gamma | |- | 3 | Storage 3 #3 | ²²Na | 1 | 37 | 2013 | 2.6 y | 511, 1 275 keV gamma | |- | 4 | Storage 3 #4 | ⁵⁷Co | 1 | 37 | 2013 | 272 d | 122 keV gamma | |- | 5 | Storage 3 #5a | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 6 | Storage 3 #5b | ⁶⁰Co | 1 | 37 | 2005 | 5.3 y | 1 173, 1 333 keV gamma | |- | 7 | Storage 3 #6 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 3 #7 | ²⁴¹Am | 1 | 37 | 1976 | 458 y | Alpha + 60 keV gamma | Glass tube set |- | 9 | Storage 3 #8 | ⁹⁰Sr | 1 | 37 | 1976 | 29 y | e^- | Glass tube set |- | 10 | Storage 3 #9 | ⁵⁵Fe | 10 | 370 | 1976 | 30 y | 662 keV gamma | Glass tube set |- | 11 | Storage 3 #10 | ¹⁰⁶Ru | 2.7 | 100 | 2000 | 374 d | e^- | |- | 12 | Storage 3 #11 | ²⁴¹Am | 10 | 370 | 1975 | 458 y | Alpha + 60 keV gamma | ORTEC AM-1U, S/N M-1343, act. 0.088 |- | 13 | Storage 3 #12 | ⁹⁰Sr | 2 000 | 74 000 | 2022 | 29 y | e^- | VZ-3721-001 Capsule, Nominal, Φ 8mm x 5mm |- |} ===Storage 2=== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 2 #1a | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 2 | Storage 2 #1b | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 3 | Storage 2 #1c | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 4 | Storage 2 #1d | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 5 | Storage 2 #1e | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 6 | Storage 2 #1f | ¹³⁷Cs | 5 | 185 | 2003 | 30 y | 662 keV gamma | |- | 7 | Storage 2 #2 | ¹³⁷Cs | 5 | 185 | 1999 | 30 y | 662 keV gamma | |- | 8 | Storage 2 #3a | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 9 | Storage 2 #3b | ⁹⁰Sr | 0.1 | 3.7 | 2005 | 29 y | e^- | |- | 10 | Storage 2 #4a | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 11 | Storage 2 #4b | ²¹⁰Po | 0.1 | 3.7 | 2005 | 138 d | 803 keV gamma | |- | 12 | Storage 2 #5a | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 13 | Storage 2 #5b | ¹³⁷Cs | 5 | 185 | 1972 | 30 y | 662 keV gamma | |- | 14 | Storage 2 #6 | ⁶⁰Co | 5 | 185 | 1972 | 5.3 y | 1 173, 1 333 keV gamma | |- | 15 | Storage 2 #7 | ¹⁵²Eu | 0.04 | 1.5 | 2006 | 13.5 y | Many gamma lines | Sealed Liquid |- | 16 | Storage 2 #8a | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 17 | Storage 2 #8b | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 18 | Storage 2 #8c | ²²Na | 1 | 37 | 2005 | 2.6 y | 511, 1 275 keV gamma | |- | 19 | Storage 2 #9a | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 20 | Storage 2 #9b | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 21 | Storage 2 #9c | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 22 | Storage 2 #9d | ¹³⁷Cs | 0.5 | 18.5 | 2005 | 30 y | 662 keV gamma | |- | 23 | Storage 2 #10 | ¹⁵²Eu | 1 | 37 | 2005 | 13.5 y | Many gamma lines | |- | 24 | Storage 2 #11a | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 25 | Storage 2 #11b | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 26 | Storage 2 #11c | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 27 | Storage 2 #11d | ²⁰⁴Tl | 10 | 370 | 1993 | 3.78 y | 511 keV gamma | Al housing |- | 28 | Storage 2 #12a | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 29 | Storage 2 #12b | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 30 | Storage 2 #12c | ²²⁶Ra | 0.09 | 3.3 | 2005 | 1 600 y | 186 keV gamma | Glass jar |- | 31 | Storage 2 #13 | ²⁴¹Am | 0.24 | 9 | N/A | 458 y | 60 keV gamma | GDM 625 |- | 32 | Storage 2 #14 | ¹³⁷Cs | 1.22 | 45 | N/A | 30 y | 662 keV gamma | GDM 134 |- | 33 | Storage 2 #15 | UO₂ | N/A | N/A | N/A | N/A | N/A | Nuclear fuel pellet (black cylinder in epoxy cube) |- |} ===Storage 1=== ====White==== {| class="wikitable" |- ! Item ! Source ID ! Isotope ! Activity, µCi ! Aktivity, kBq ! Year ! Half-life ! Radiation type ! Note |- | 1 | Storage 1W #1 | ²⁴¹Am | 10 000 | 370 000 | | 458 y | X-rays | Variable X-ray source |- | 2 | Storage 1W #2 | ²⁴¹Am | 10 | 370 | 1993 | 458 y | 60 keV gamma | DA289 written on the source |- | 3 | Storage 1W #3 | ⁶⁰Co | 10 | 370 | 1970 | 10.5 y | 1 173, 1 333 keV gamma | A943F |- | 4 | Storage 1W #4 | ¹⁴⁷Pm | 10 000 | 370 000 | 1974 | 2.6 y | 76, 198 keV gamma | A1124/N11958 |- | 5 | Storage 1W #5 | ¹³⁷Cs | 10 | 370 | | 30 y | 662 keV gamma | S/N 15319; A919F |- | 6 | Storage 1W #6 | ⁶⁰Co | 1 | 37 | | 10.5 y | 1 173, 1 333 keV gamma | S/N 811-L-1 |- | 7 | Storage 1W #7 | ²⁴¹Am | 0.1 | 3.7 | 1966 | 458 y | 60 keV gamma | A922F; S/N M954 Ortec |- | 8 | Storage 1W #8 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 9 | Storage 1W #9 | ¹³⁷Cs | 100 | 3 700 | 1984 | 30 y | 662 keV gamma | |- | 10 | Storage 1W #10 | ²⁴¹Am | 14 000 | 518 000 | 1984 | 458 y | 60 keV gamma | M55005 |- | 11 | Storage 1W #11 | ²⁴¹Am | 10 000 | 370 000 | 2010 | 458 y | 60 keV gamma | |- | 12 | Storage 1W #12 | ²²⁶Ra | 5-10 | 185-370 | 1970 | 1 600 y | 186 keV gamma | A859F; Leybold in a jar |- | 13 | Storage 1W #13 | ¹³⁷Cs | <10 | <370 | 2005 | 30 y | 662 keV gamma | Isotope generator |- | 14 | Storage 1W #14a | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 15 | Storage 1W #14b | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 16 | Storage 1W #14c | ²³⁸U | 1 | 37 | 2006 | 4.5e9 y | 50, 114 keV gamma + alpha | Liquid in plastic bottles (B. Stugu’s) |- | 17 | Storage 1W #15 | ⁹⁰Sr | 2 000 | 74 000 | 1987 | 29 y | e^- | Amersham (in a blue cylindrical collimator) |- | 18 | Storage 1W #16 | | | | 1945 | | | Hiroshima dust |- | 19 | | | 0 | 0 | 2005 | | | Eluting solution for Tilf #13 Isotope generator |- | 20 | Storage 4 #5 | ²²⁶Ra | 2.7 | 100 | ~1970 | 1 600 y | 186 keV gamma | Previously stored in Lab 420 |- |} ====Black==== {| class="wikitable" |- ! Item ! Source ID ! Activity, counts/s* ! Note |- | 1 | Storage 1B #1 | ~20 | Storage 1B R. 1 |- | 2 | Storage 1B #2 | ~120 | Storage 1B G. 1 |- | 3 | Storage 1B #3 | ~60 | Storage 1B G. 2 |- | 4 | Storage 1B #4 | ~100 | Storage 1B G. 3 |- | 5 | Storage 1B #5 | ~10 | Storage 1B G. 4 |- | 6 | Storage 1B #6 | ~10 | Storage 1B G. 5 |- | 7 | Storage 1B #7 | ~0 | Storage 1B G. 6 |- | 8 | Storage 1B #8 | ~220 | Storage 1B G. 7 |- | 9 | Storage 1B #9 | ~150 | Storage 1B G. 8 |- | 10 | Storage 1B #10 | ~10 | Storage 1B G. 9 |- | 11 | Storage 1B #11 | ~350 | Storage 1B G. 10 |- | 12 | Storage 1B #12 | ~500 | Storage 1B G. 11 |- | 13 | Storage 1B #13 | ~1 000 | Storage 1B G. 12 |- |} <nowiki>*</nowiki>Activity measured with an 1" NaI(Tl) crystal 48153f8eb9fd3d8839296c2cdd3839e5b6c89967 4 684 2888 2798 2022-11-24T16:18:20Z Nfo058 90 wikitext text/x-wiki User:Nfyal User:Nfyst User:Nfo058 User:bla008 f967481443906fa6cd075e600dc5144d67e8f518 2889 2888 2022-11-24T16:25:20Z Nfo058 90 wikitext text/x-wiki User:Nfyal User:Nfyst User:Nfo058 User:Bla008 df30e86b6d4758c6ec6a4cea10b6389f698451ed 2891 2889 2022-11-24T16:48:32Z Nfo058 90 wikitext text/x-wiki User:Nfyal User:Nfyst User:Nfo058 61bafb8cd3ee45734438153f17d0f8e9460b3b5f 2 703 2890 2022-11-24T16:42:29Z Nfo058 90 Created page with "Test." wikitext text/x-wiki Test. 748d77dbb8bdb0dd330c099e7fde82da053fb1ff 0 137 2894 2858 2022-11-29T09:18:09Z Bla008 79 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas2.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics was funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway until 2020. Now we are a part of Center for CERN Related Research. HistorY: The last HEPP funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). We are also involved in the [http://www.cta-observatory.org/ Cherenkov Telescope Array]. [[Cherenkov_Telescope_Array_-_Norway|Click here for more info]]. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * [[The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page] ]] * [[Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page]]] * [[From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page]]] === Job openings in our group=== all our jobs are listed in [https://www.jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] f0b9065296611b0279621e722eb9af9187dec40e 2895 2894 2022-11-29T09:22:08Z Bla008 79 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. (We also have our internal Wiki, at A0 , UiB Wiki [http://atlas2.ift.uib.no/wiki/index.php/Main/HomePage here] with information which is not public outside ATLAS-Bergen. ) Particle Physics was funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway until 2020. Now we are a part of Center for CERN Related Research. HistorY: The last HEPP funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). We are also involved in the [http://www.cta-observatory.org/ Cherenkov Telescope Array]. [[Cherenkov_Telescope_Array_-_Norway|Click here for more info]]. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page] * Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page] * From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page] === Job openings in our group=== all our jobs are listed in [https://www.jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 7748f401d9670b8ef5163678000c7d269445ce69 2896 2895 2023-08-17T11:26:26Z Bla008 79 wikitext text/x-wiki == Particle Physics == [[Image:atlas_banner.jpg]] Wiki page for Bergen University Particle Physics Group. (We also have our internal ATLAS UiB twiki [https://twiki.cern.ch/twiki/bin/view/AtlasProtected/AtlasBergen here] with information which is not public outside ATLAS-Bergen. ) Particle Physics was funded by the HEPP (High Energy Particle Physics) programme of the Research Council of Norway until 2020. Now we are a part of Center for CERN Related Research. HistorY: The last HEPP funding application description (mostly funded) for the period 2016-2019 can be read here [[File:ProjectDescription2015.pdf]]. The report from the September 2016- September 2017 activity can be found here [[File:HEPP-2017-report-not-final.pdf]]. You can also read up on responsibilities of your local ATLAS group team leader as seen from CERN point of view here [[File:CERN_Team_Leader_Responsibilities.pdf]] In years 2020-2024 we are a part of the Grieg project, "Early Universe", see twiki here: [https://wiki.uib.no/ift/index.php/GRIEG_project_%22EarlyUniverse%22 Grieg "EarlyUniverse"] To get write access to these pages below you must have a UiB account, then you have to login using the login in link in the upper right corner of the wiki page, once you've done this send an e-mail and Anna Lipniacka (temporary info) and she will figure out who can activate your account (probably Kjetil). We are also involved in the [http://www.cta-observatory.org/ Cherenkov Telescope Array]. [[Cherenkov_Telescope_Array_-_Norway|Click here for more info]]. === [[ParticlePhysicsGroupMeetings|Meetings, Seminars & Tutorials]] === === [[ATLASThesesNotes|Theses, Notes, Publications, Public Software]] === === [[ATLASTutorials|ATLAS Tutorials]] === === [[HEPOutreach|HEP Outreach]] === === [http://atlassec.web.cern.ch/atlassec/Registration.htm ATLAS newcomers] === === Local Conferences === * The Dark Side of the Universe, DSU2016 25-29 July 2016 [https://indico.cern.ch/event/459881/ agenda page] * Nordic b-annual particle physics meeting [http://www.hip.fi/spatind2016 agenda page] * From Higgs to Dark Matter 2014, , [http://indico.cern.ch/e/geilo-2014 indico page] === Job openings in our group=== all our jobs are listed in [https://www.jobbnorge.no jobbnorge.no] * [[ ]] ===Misc and AoB=== * Talks by group members part 1, some of them not public [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22orjan%20dale%22%20OR%20%22lipniacka%22%20OR%20%22latour%22%20OR%20%22sjursen%22%20OR%20%22liebig%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * Talks by group members, some of them visible only to ATLAS, part 2 [https://search.cern.ch/Pages/IndicoFrame.aspx?isFrame=1&k=author%3A%22fomin%22%20OR%20%22maeland%22%20OR%20%22zalieckas%22%20OR%20%22zongchang%20yang%22%20OR%20%22stugu%22%20OR%20%22hellesund%22%20OR%20%22eigen%22&isDlg=1&httpsActivation=1&autologin=1&v1=%2Dwrite&r=format%3D%22ARMBSW5kaWNvIENvbnRyaWJ1dGlvbgZmb3JtYXQBAl4iAiIk%22 here] * News from Sierra Nevada on extreme lightning: [http://yubanet.com/scitech/two-new-lightning-extremes-announced/ here] * Links to ift-posten from 2016 [http://org.uib.no/ift-posten/IFT-posten2016/ here] and 2017 [http://org.uib.no/ift-posten/IFT-posten2017/ here] * CERN summer student program [https://home.cern/students-educators/summer-student-programme about and how to apply] * Isaac Newton a hermit and a tyrant, BBC documentary [https://www.academicvideostore.com/video/isaac-newton-last-magician here] Last changes: [AL] 16:30, 24 september 2016 (CET) [[Category:Particle Physics]] 913a7718722d6524c2f2c945333d3a95dd4bd0d4 0 693 2897 2865 2023-08-29T08:03:43Z Jdj005 113 /* Information for beginners */ wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. = Information for beginners = Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Introductory talk about DM searches at CTA: https://www.youtube.com/watch?v=g2tyOIsy1kQ * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Introduction to Gammapy 1.0 by Axel (Scipy 2023): https://youtu.be/NOX-jVj4IPA?si=YCUpFMTNkXFs0akm and slides: https://doi.org/10.25080/gerudo-f2bc6f59-0282023): * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 * Equatorial coordinate system explained: https://www.youtube.com/watch?v=WvXTUcYVXzI * Rather lengthy and detailed introduction to the field: https://arxiv.org/abs/2111.01198 == Registering new arrivals == The group leader has to add the name to this list: https://portal.cta-observatory.org/Bodies/ProjectOffice/Lists/People/Grouped.aspx and then an email has to be sent to Tiziana to ask for an account for the CTA web services. 2c06ab19e1b2a386dfccd94097e4c0201e1a0080 2898 2897 2023-08-29T08:04:14Z Jdj005 113 wikitext text/x-wiki Several Norwegian institutes are involved in the [https://www.cta-observatory.org/ Cherenkov Telescope Array] (CTA) - a next level observatory for gamma ray astronomy. We have [https://indico.cern.ch/category/10575/ regular meetings] and currently focus on Dark Matter searches with CTA. Here, we collect some information for collaboration. = Information for beginners = Below are some links to introduce you to what we are doing. * CTA obseratory website: https://www.cta-observatory.org/ * The software we use: https://docs.gammapy.org/0.18.2/index.html * Suggested reading: Chapter 4 of the paper "Science with CTA" (nice introduction, then it gets more specific) https://arxiv.org/abs/1709.07997 * Short video about how CTA works: https://www.youtube.com/watch?v=5gRHFQP_SjU * Scientific talk about the CTA observatory (status and perspective): https://www.youtube.com/watch?v=1yXTQbF9hsg&feature=youtu.be&ab_channel=UlissesBarresdeAlmeida * Introductory talk about DM searches at CTA: https://www.youtube.com/watch?v=g2tyOIsy1kQ * Talk about Searching for DM with CTA (at least the intro is nice then it gets rather specific in the end): https://www.youtube.com/watch?v=idixr03VTDs&feature=youtu.be&ab_channel=CsabaBalazs * Introduction to Gammapy 1.0 by Axel (Scipy 2023): https://youtu.be/NOX-jVj4IPA?si=YCUpFMTNkXFs0akm and slides: https://doi.org/10.25080/gerudo-f2bc6f59-0282023 * Talk on gamma-ray, CTA and gammapy: https://www.youtube.com/watch?v=kL8TWYcF0h8&ab_channel=LabExUnivEarthS * More detailed talk on gammapy by Axel (this can be used for getting started with gammapy. The jupyter notebooks that he discusses can be downloaded here: https://github.com/escape2020/school2021/tree/main/gammapy first he uses the gammapy-overview.ipynb and then gammapy-cta-gc.ipynb): https://www.youtube.com/watch?v=gsAI0TDV5B0&ab_channel=ESCAPE_EU * If you want a deeper understanding of the underlying python packages, here you can find talks on astropy, scipy, matplotlib, and numpy: https://www.youtube.com/channel/UC05braEQdP2rCSUamHm9I_Q/videos with the corresponding notebooks here: https://github.com/escape2020/school2021 * Equatorial coordinate system explained: https://www.youtube.com/watch?v=WvXTUcYVXzI * Rather lengthy and detailed introduction to the field: https://arxiv.org/abs/2111.01198 == Registering new arrivals == The group leader has to add the name to this list: https://portal.cta-observatory.org/Bodies/ProjectOffice/Lists/People/Grouped.aspx and then an email has to be sent to Tiziana to ask for an account for the CTA web services. a0d99c7e654679d6f4a0d0951dd42f3848fd9561 0 34 2901 2813 2024-01-24T07:54:24Z Nfyku 4 /* Starte Questa Sim */ wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. Generelt ligger programvaren i /eda/Siemens, og versjonene ligger i mapper sortert på årstall. ssh -X mikroserver4 export LM_LICENSE_FILE=1717@lisensserver source /eda/Siemens/2023-24/scripts/QUESTA-CORE-PRIME_2023.4_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet: vsim -voptargs=+acc sign_var Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid? <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (clk : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference p_test: process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process p_test; end architecture difference; </pre> 6a0ca52d039d48076a2daa6333a72a8d07656e10 2904 2901 2024-05-30T11:39:53Z Nfyku 4 wikitext text/x-wiki ===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa=== ==Innledning== Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler: * Eksempel 1: Signalflyt i en SR-lås * Eksempel 2: Signaler og variable Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under. ==Starte Questa Sim== Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu. Generelt ligger programvaren i /eda/Siemens, og versjonene ligger i mapper sortert på årstall. ssh -X mikroserver4 export LM_LICENSE_FILE="Sett inn rett lisensserver og port her" source /eda/Siemens/2023-24/scripts/QUESTA-CORE-PRIME_2023.4_RHELx86.sh vsim ==Lage et nytt prosjekt== I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen. Start et nytt prosjekt med <pre> File > New > Project </pre> [[Image:questa_new_project.png]] Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt. Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch ==Skriving av VHDL kode== En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File. Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl). ==Kompilering av VHDL kode== Koden kompileres med <pre> vcom sr_latch.vhdl </pre> Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren. Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen. ==Simulering og debugging i Questa== Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med: <pre> vsim </pre> Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer: * View > Wave * View > Objects * View > Locals Man kan også gi kommandoer i Questa-vinduet. F.eks. <pre> Wave * </pre> Dra de signalene du vil se på i wave vinduet fra object vinduet. Signalverdier settes med kommandoen 'force' eller med <pre> Force > Force (i "Signals" vinduet) </pre> Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med <pre> Force > Clock (i "Signals" vinduet) </pre> ==Eksempler== ===Signalflyt i en SR-lås=== Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført. Hvis du vil begynne på ny kan du velge <pre> File > Restart -f </pre> <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY SR_latch IS PORT ( S,R : IN std_logic ; Q,QB : INOUT std_logic ); END SR_latch; ------------------------------------------------------------------------------- ARCHITECTURE behave OF SR_latch IS BEGIN -- behave Q <= S nand QB; QB <= R nand Q; END behave; </pre> ===Signaler og variable=== Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet: vsim -voptargs=+acc sign_var Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid? <pre> LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY sign_var IS PORT (clk : IN std_logic); END sign_var; ------------------------------------------------------------------------------- ARCHITECTURE difference OF sign_var IS signal SA: bit := '0'; signal SB: bit := '1'; begin -- difference p_test: process variable A: bit := '0'; variable B: bit := '1'; begin wait until rising_edge(clk); A := B; B := A; SA <= SB after 5 ns; SB <= SA after 5 ns; end process p_test; end architecture difference; </pre> 8ecec7e3830f4949613236bcdabc681363978348 0 36 2902 2819 2024-01-24T07:58:50Z Nfyku 4 /* Precision */ wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver source /eda/Siemens/2023-24/scripts/PRECISION_2023.2_RHELx86.sh precision Erstatt lisensserver med rett navn på lisensserver.Nye versjoner av programvaren ligger i /eda/Siemens sortert på årstall. Velg deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps -sdfnoerror -sdfmax /alu_synth=/home/kaf003/VHDL_Prosjekter/PHYS321/vivado_impl_1/add_sub_alu_synth.sdf work.alu_tb Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk : std_logic; signal reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end architecture struct; </pre> [[Category:Mikroelektronikk]] 02708baa3b81903c37c3568ef4ae4746b18d96f3 2905 2902 2024-05-30T11:43:00Z Nfyku 4 wikitext text/x-wiki ===Syntetiseringen av VHDL kode=== Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets. Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel. ==Precision== Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet: export LM_LICENSE_FILE=27001@lisensserver1:29000@lisensserver2 source /eda/Siemens/2023-24/scripts/PRECISION_2023.2_RHELx86.sh precision Erstatt lisensserver med rett navn på lisensserver (se "Micro-how-to" i mikroelektronikk-teamet).Nye versjoner av programvaren ligger i /eda/Siemens sortert på årstall. Velg deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd). Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok. Pass på at Precision finner Vivado, settes i menyen: Tools > Options > Place and Route Settings deretter Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree settes til /eda/xilinx/Vivado/2020.2 Trykk så compile, og synthesize. No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side. ==Questasim== Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd'). Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen Tools > Compile Simulation Libraries men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik: vmap unisim /eda/xilinx/lib/unisim Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns: test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong). Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen. ==Simulering med timing== Eksempel på start av simulering med timing: vsim -t ps -sdfnoerror -sdfmax /alu_synth=/home/kaf003/VHDL_Prosjekter/PHYS321/vivado_impl_1/add_sub_alu_synth.sdf work.alu_tb Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda. ==Konklusjon== Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn. ==Kode== ===Kode til add_sub_alu.vhd=== <pre> LIBRARY ieee; USE ieee.std_logic_1164.All; USE ieee.std_logic_unsigned.all; ENTITY add_sub_alu IS PORT ( clk : IN std_logic; rst : IN std_logic; enable_in : IN std_logic; start : IN std_logic; enable : IN std_logic; do_add : IN std_logic; do_subtract : IN std_logic; do_hold : IN std_logic; data_in : IN std_logic_vector(3 DOWNTO 0); data_out : OUT std_logic_vector(3 DOWNTO 0) BUS); END add_sub_alu; ARCHITECTURE algorithm OF add_sub_alu IS TYPE states IS (hold, reset, add, subtract); SIGNAL state_var : states; SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0); SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0); BEGIN latch: PROCESS (enable_in, data_in)is BEGIN IF (enable_in = '1') THEN latched_data_in <= data_in; END IF; END PROCESS latch; fsm: PROCESS (clk, rst) is BEGIN IF (rst = '0') THEN state_var <= reset; ELSIF rising_edge(clk) THEN CASE state_var IS WHEN hold => IF (start = '1') THEN state_var <= reset; END IF; WHEN reset => IF (do_add = '1') THEN state_var <= add; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN add => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_subtract = '1') THEN state_var <= subtract; END IF; WHEN subtract => IF (do_hold = '1') THEN state_var <= hold; ELSIF (do_add = '1') THEN state_var <= add; END IF; WHEN OTHERS => state_var <= reset; END CASE; END IF; END PROCESS fsm; alu: PROCESS (state_var, latched_data_in, reg)is BEGIN CASE state_var IS WHEN add => int_reg <= reg + latched_data_in; WHEN subtract => int_reg <= reg - latched_data_in; WHEN reset => int_reg <= (others => '0'); WHEN hold => int_reg <= reg; WHEN OTHERS => int_reg <= reg; END CASE; END PROCESS alu; mem: PROCESS (clk) is BEGIN IF rising_edge(clk) THEN reg <= int_reg; END IF; END PROCESS mem; tri: PROCESS (enable, reg) is BEGIN FOR i IN 3 DOWNTO 0 LOOP IF (enable = '1') THEN data_out(i) <= reg(i); ELSE data_out(i) <= 'Z'; END IF; END LOOP; END PROCESS tri; END algorithm;</pre> ===Koden til alu_tb.vhdl=== <pre> library ieee; use ieee.std_logic_1164.all; library work; use work.all; entity alu_tb is end entity alu_tb; architecture struct of alu_tb is --Deklaring av signal som skal koblast til komponentane. --Alle innsignal er felles, medan vi har 2 forskjellige utsignal. signal clk : std_logic; signal reset : std_logic; signal enable_in : std_logic; signal start : std_logic; signal enable : std_logic; signal do_add : std_logic; signal do_subtract : std_logic; signal do_hold : std_logic; signal data_in : std_logic_vector(3 downto 0); signal data_out : std_logic_vector(3 downto 0); signal data_out_synt : std_logic_vector(3 downto 0); begin --Deklarer komponenten alu. alu : entity add_sub_alu(algorithm) --Kobler signala til den opprinnelige komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out); --Deklarer komponenten alu_synt. alu_synt : entity add_sub_alu_synth(structure) --Kobler signala til den synthiserte komponenten. port map ( clk => clk, rst => reset, enable_in => enable_in, start => start, enable => enable, do_add => do_add, do_subtract => do_subtract, do_hold => do_hold, data_in => data_in, data_out => data_out_synt); --Klokkegenerator clock_gen : process begin clk <= '0', '1' after 50 ns; wait for 100 ns; end process clock_gen; --Setter testvektorane. reset <= '0', '1' after 60 ns; enable <= '1', '0' after 900 ns; enable_in <= '1', '0' after 400 ns; start <= '1', '0' after 300 ns; do_add <= '1', '0' after 660 ns; do_subtract <= '0'; do_hold <= '0'; data_in <= X"3"; --Test process for å samanlikne utsignala kvart nanosekund. test : process begin wait for 1 ns; assert (data_out = data_out_synt) report "Data ut er ulik" severity Error; end process test; end architecture struct; </pre> [[Category:Mikroelektronikk]] c9544169c492ad1b192f553d873f37184d6c9cb2 0 481 2903 2836 2024-02-13T12:14:01Z Nfyku 4 /* Simulation */ wikitext text/x-wiki This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT IMPORTANT - READ BEFORE USING OR COPYING. THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT ------------------------------------------------------------------ Copyright (c) 2016 by Bitvis AS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref> The presentation can also be found in the uvvm_util folder. == Introduction == Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github]. === What's in the folders? === [[File:20160302215840!1.png|thumb]] The download includes severals folders: * bitvis_irqc - example VHDL design + testbench * bitvis_uart - example VHDL design + testbench * bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI) * bitvis_vip_uart - VIP for UART TX and RX * uvvm_util - UVVM utility library - sufficient for simple testbenches * uvvm_vvc_framework - Framework for more advanced tutorials === IRQC === [[File:irqc.png|thumb]] The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals. [[File:irqc2.png|350px]] == UVVM Utility Library - Testbench creation == Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files. === Generate TB entity with DUT instantiated === Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata). <pre> --Standard libraries library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; -- Library enabling control of the simulation from VHDL. Eg. std.env.stop library STD; use std.env.all; -- Obviously the UVVM library library uvvm_util; context uvvm_util.uvvm_util_context; -- We will use this library later when implementing the Bus Functional Model -- Includes among much else the record type t_sbi_if and many functions -- If other buses are used, you will have to change this library library bitvis_vip_sbi; use bitvis_vip_sbi.sbi_bfm_pkg.all; -- This file includes definitions of everything from registers to record types use work.irqc_pif_pkg.all; -- Test case entity entity irqc_tb is end entity; -- Test case architecture architecture func of irqc_tb is -- DSP interface and general control signals signal clk : std_logic := '0'; signal arst : std_logic := '0'; -- CPU interface -- t_sbi_if is from the verification IP SBI -- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8); -- Interrupt related signals signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0'); signal irq2cpu : std_logic := '0'; signal irq2cpu_ack : std_logic := '0'; begin ----------------------------------------------------------------------------- -- Instantiate DUT ----------------------------------------------------------------------------- i_irqc: entity work.irqc port map ( -- DSP interface and general control signals clk => clk, arst => arst, -- CPU interface cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF addr => sbi_if.addr, wr => sbi_if.wena, rd => sbi_if.rena, din => sbi_if.wdata, dout => sbi_if.rdata, -- Interrupt related signals irq_source => irq_source, irq2cpu => irq2cpu, irq2cpu_ack => irq2cpu_ack ); end func; </pre> === Add support process for clock generation === We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture: <pre> -- Added for clock generation signal clock_ena : boolean := false; constant C_CLK_PERIOD : time := 10 ns; procedure clock_gen( signal clock_signal : inout std_logic; signal clock_ena : in boolean; constant clock_period : in time ) is variable v_first_half_clk_period : time := C_CLK_PERIOD / 2; begin loop if not clock_ena then wait until clock_ena; end if; wait for v_first_half_clk_period; clock_signal <= not clock_signal; wait for (clock_period - v_first_half_clk_period); clock_signal <= not clock_signal; end loop; end; </pre> Our clock can now be activated from the test sequencer (this will be added in the next step): <pre> -- After begin in the architecture clock_gen(clk, clock_ena, C_CLK_PERIOD); -- Inside the test sequencer process clock_ena <= true; </pre> === Add test sequencer process === The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation. <pre> -- Set upt clock generator clock_gen(clk, clock_ena, C_CLK_PERIOD); ------------------------------------------------ -- PROCESS: p_main ------------------------------------------------ p_main : process -- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope constant C_SCOPE : string := C_TB_SCOPE_DEFAULT; -- This is where we will add some procedures later to simplify the tests begin --Print the configuration to the log report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); --disable_log_msg --enable_log_msg(ID_LOG_HDR); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); ------------------------------------------------------------ clock_ena <= true; -- to start clock generator ------------------------------------------------------------ -- End the simulation wait for 1000 ns; -- to allow some time for completion report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail) log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); --Finish the simulation std.env.stop; wait; -- to stop completely end process p_main; </pre> ==Simulation== We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim. Change directory to the script folder (where you have copied the UVVM files), for example in phys321/bitviswiki.....: <pre> cd ~/phys321/bitviswiki/bitvis_irqc/script do compile_and_sim_all.do </pre> This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code: <pre> report_global_ctrl(VOID); report_msg_id_panel(VOID); enable_log_msg(ALL_MESSAGES); log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE); report_alert_counters(FINAL); log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE); </pre> Commenting these out will result in an empty log. == Verbosity control == We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want. To turn on a specific ID <pre> enable_log_msg(IDNAME); </pre> Turn off: <pre> disable_log_msg(IDNAME); </pre> For writing a message to a certain log ID: <pre> log(IDNAME, "MESSAGE HERE", C_SCOPE); </pre> Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file. Exampled IDs: * ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers * ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers) * ID_BFM, -- Used inside a BFM (to log BFM access) * ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled * ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined. == Implement first tests == [[File:tb.png|thumb|upright=0.35]] We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT. Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin): <pre> procedure set_inputs_passive( dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability begin sbi_if.cs <= '0'; sbi_if.addr <= (others => '0'); sbi_if.wena <= '0'; sbi_if.rena <= '0'; sbi_if.wdata <= (others => '0'); irq_source <= (others => '0'); irq2cpu_ack <= '0'; log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE); end; </pre> Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable: <pre> set_inputs_passive(VOID); </pre> Rather than: <pre> set_inputs_passive; </pre> which is more ambigious. We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure: <pre> procedure pulse( signal target : inout std_logic_vector; constant pulse_value : in std_logic_vector; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= pulse_value; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= pulse_value; wait for 0 ns; -- Delta cycle only end if; target(target'range) <= (others => '0'); log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE); end; </pre> In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form: <pre> pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'"); </pre> But a more specific overload can be created where pulse always takes value '1': <pre> procedure pulse( signal target : inout std_logic; signal clock_signal : in std_logic; constant num_periods : in natural; constant msg : in string ) is begin if num_periods > 0 then wait until falling_edge(clock_signal); target <= '1'; for i in 1 to num_periods loop wait until falling_edge(clock_signal); end loop; else target <= '1'; wait for 0 ns; -- Delta cycle only end if; target <= '0'; log(ID_SEQUENCER_SUB, msg, C_SCOPE); end; </pre> These procedures can now be called directly from our test sequence: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "pulsed reset-signal - active for 10T"); </pre> To check signal values we can use the built-in check function check_value(): <pre> check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); </pre> The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message: [[File:error.png|700px]] If we want we can change the number of errors logged before the simulation stops: <pre> set_alert_stop_limit(ERROR, 3); </pre> We now have all the tools needed for the first tests in our sequencer: <pre> set_inputs_passive(VOID); pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T"); check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE); check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE); log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE); ------------------------------------------------------------ check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE); check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive"); </pre> This will give us the following log: [[File:sim.png|800px]] This information may only interesting initially and for debug, and can be turned on or off by use of ID. == Subprograms == Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is: - Register access - Signal checkers - Interrupt source pulsing? - Interrupt acknowledge pulsing? - (Report/log method) - (Alert-handling) - (reset, set_passive, ...) We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures: <pre> -- Log overloads for simplification procedure log( msg : string) is begin log(ID_SEQUENCER, msg, C_SCOPE); end; </pre> This exact function is already overloaded in the UVVM packages, so including this in our testbench would produce compilation errors. So, let's not include it, but view it as an example of how it's done. Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources. <pre> subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0); -- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width) function trim( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return t_irq_source is variable v_result : std_logic_vector(source'length-1 downto 0) := source; begin return v_result(num_bits-1 downto 0); end; -- Fit a given vector to the number of irq sources by masking with zeros above irq width function fit( constant source : std_logic_vector; constant num_bits : positive := C_NUM_SOURCES) return std_logic_vector is variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0'); variable v_source : std_logic_vector(source'length-1 downto 0) := source; begin v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0); return v_result; end; </pre> All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other. == Register access == To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values: <pre> procedure sbi_check ( constant addr_value : in unsigned; constant data_exp : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant alert_level : in t_alert_level := error; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_check"; constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); -- Helper variables variable v_data_value : std_logic_vector(rdata'length - 1 downto 0); variable v_check_ok : boolean; variable v_clk_cycles_waited : natural := 0; begin sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name); -- Compare values, but ignore any leading zero's if widths are different. -- Use ID_NEVER so that check_value method does not log when check is OK, -- log it here instead. v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call); if v_check_ok then log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); end if; end procedure; </pre> We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value. <pre> procedure sbi_read ( constant addr_value : in unsigned; variable data_value : out std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal rdata : in std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT; constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check ) is constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalize to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_data_value : std_logic_vector(data_value'range); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '0'; rd <= '1'; addr <= v_normalised_addr; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; rd <= '0'; v_data_value := rdata; data_value := v_data_value; if proc_name = "sbi_read" then log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel); else -- Log will be handled by calling procedure (e.g. sbi_check) end if; end procedure; </pre> We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench: <pre> procedure check( constant addr_value : in natural; constant data_exp : in std_logic_vector; constant alert_level : in t_alert_level; constant msg : in string) is begin sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg, clk, sbi_if, alert_level, C_SCOPE); end; </pre> The write procedure is also very handy and should be understood: <pre> procedure sbi_write ( constant addr_value : in unsigned; constant data_value : in std_logic_vector; constant msg : in string; signal clk : in std_logic; signal cs : inout std_logic; signal addr : inout unsigned; signal rd : inout std_logic; signal wr : inout std_logic; signal ready : in std_logic; signal wdata : inout std_logic_vector; constant scope : in string := C_SCOPE; constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel; constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT ) is constant proc_name : string := "sbi_write"; constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")"; -- Normalise to the DUT addr/data widths variable v_normalised_addr : unsigned(addr'length-1 downto 0) := normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg); variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) := normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg); variable v_clk_cycles_waited : natural := 0; begin wait_until_given_time_after_rising_edge(clk, config.clock_period/4); cs <= '1'; wr <= '1'; rd <= '0'; addr <= v_normalised_addr; wdata <= v_normalised_data; wait for config.clock_period; while (config.use_ready_signal and ready = '0') loop if v_clk_cycles_waited = 0 then log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel); end if; wait for config.clock_period; v_clk_cycles_waited := v_clk_cycles_waited + 1; check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity, ": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call); end loop; cs <= '0'; wr <= '0'; log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel); end procedure; </pre> We will create a local overload of this too: <pre> procedure write( constant addr_value : in natural; constant data_value : in std_logic_vector; constant msg : in string) is begin sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg, clk, sbi_if, C_SCOPE); end; </pre> We also need to set the sbi_if.ready signal high for this to work: <pre> clock_generator(clk, clock_ena, C_CLK_PERIOD, "IRQC TB clock"); -- Insert this here by the clock generator sbi_if.ready <= '1'; -- always ready in the same clock cycle. </pre> All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc). [[File:bfm.png|550px]] == Checking register write and read == Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit(). <pre> log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE); ------------------------------------------------------------ log("\nChecking Register defaults"); check(C_ADDR_IRR, x"00", ERROR, "IRR default"); check(C_ADDR_IER, x"00", ERROR, "IER default"); check(C_ADDR_IPR, x"00", ERROR, "IPR default"); check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default"); log("\nChecking Register Write/Read"); write(C_ADDR_IER, fit(x"55"), "IER"); check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"AA"), "IER"); check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback"); write(C_ADDR_IER, fit(x"00"), "IER"); check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback"); </pre> This check will give us a nice log if everything turns out ok: [[File:sim2.png|700px]] However, if there's an error: [[File:error2.png|700px]] == Further tests == Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary. <pre> log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE); ------------------------------------------------------------ write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR"); write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts"); check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR"); write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR"); </pre> The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly. <pre> log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE); ------------------------------------------------------------ log("\nChecking interrupts and IRR"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T"); check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts"); check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses"); pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts"); check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts"); pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts"); check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses"); write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts"); check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all"); </pre> === Check stable === Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable: <pre> v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered </pre> Later we're now able to test if the signal has been holding the same value the whole period: <pre> check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE); </pre> Remember to declare the variable in the process: <pre> variable v_time_stamp : time := 0 ns; </pre> === Await value === To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately: <pre> await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE); </pre> === Other useful functions === Check the UVVM Utility Library Quick Reference for syntax details. ==== await_change() ==== Expects and waits for a change on the given signal, inside a given time window. ==== check_value_in_range() ==== Throws an error of the signal value is outside the specified minimum and maximum values. == UVVM VVC == Guide coming.... == UVVM LICENCE AGREEMENT == {{reflist}} [[Category:Mikroelektronikk]] b15b4ec244c65ff4f8cc44d4ed4de13aaed3cc98 0 466 2906 2556 2024-05-30T11:46:04Z Nfyku 4 wikitext text/x-wiki = DC operating parameters from simulation = This script can be used to print the operating point parameters of all transistors in your design and save them to a file. If you just want to view them in Virtusoso have a look at this guide instead: [[DCoperatingparameters]] == Get the DC operating points from a previous simulation == Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a test with DC analysis, and remember to check the box with "Save DC Operating Point" : [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] == Copy the file to your computer and convert the values == After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from mikroserver to another computer try this: Create a file named "Makefile" and put this into it: # target that is the first (and default) and does all the stuff below all: get fix clean # gets the file from mikroserver3 and copies it to your computer in the root of your homefolder get : scp my_user_name@mikroserver:~/tsmc/transistors.csv ~/transistors_raw.csv # converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice fix : sed -e 's/\([0-9]\+\)m/\1E-3/g' -e 's/\([0-9]\+\)u/\1E-6/g' -e 's/\([0-9]\+\)n/\1E-9/g' -e 's/\([0-9]\+\)p/\1E-12/g' -e 's/\([0-9]\+\)f/\1E-15/g' -e 's/\([0-9]\+\)a/\1E-18/g' -e 's/\([0-9]\+\)z/\1E-21/g' -e 's/\([0-9]\+\)y/\1E-24/g' -e 's/\([0-9]\+\)K/\1E+3/g' -e 's/\([0-9]\+\)M/\1E+6/g' -e 's/\([0-9]\+\)G/\1E+9/g' -e 's/\([0-9]\+\)T/\1E+12/g' transistors_raw.csv > transistors.csv # removes the not-fixed copy clean: rm transistors_raw.csv Modify the scp-command to use * The username and the correct microserver in the scp-command * change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/ * change the local folder where you want your copy to be placed, default is /home/$user/ Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder. == Open the file in Libre Office == The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] == Troubleshooting == For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]] [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 059594a1842433397809334847916a41f024f02a 2910 2906 2024-05-30T11:56:01Z Nfyku 4 wikitext text/x-wiki = DC operating parameters from simulation = This script can be used to print the operating point parameters of all transistors in your design and save them to a file. If you just want to view them in Virtusoso have a look at this guide instead: [[DCoperatingparameters]] == Get the DC operating points from a previous simulation == Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file. selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) For the IHP design kit use: selectResult('dcOpInfo) report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000) file = outfile("./transistors.csv" "a") fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.") close(file) This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a test with DC analysis, and remember to check the box with "Save DC Operating Point" : [[File:Run_debug_simulation.png | 500px]] After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code> [[File:Run_transistors_script.png]] == Copy the file to your computer and convert the values == After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from the mikroserver you use to another computer try this: Create a file named "Makefile" and put this into it: # target that is the first (and default) and does all the stuff below all: get fix clean # gets the file from your mikroserver and copies it to your computer in the root of your homefolder get : scp my_user_name@mikroserver:~/tsmc/transistors.csv ~/transistors_raw.csv # converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice fix : sed -e 's/\([0-9]\+\)m/\1E-3/g' -e 's/\([0-9]\+\)u/\1E-6/g' -e 's/\([0-9]\+\)n/\1E-9/g' -e 's/\([0-9]\+\)p/\1E-12/g' -e 's/\([0-9]\+\)f/\1E-15/g' -e 's/\([0-9]\+\)a/\1E-18/g' -e 's/\([0-9]\+\)z/\1E-21/g' -e 's/\([0-9]\+\)y/\1E-24/g' -e 's/\([0-9]\+\)K/\1E+3/g' -e 's/\([0-9]\+\)M/\1E+6/g' -e 's/\([0-9]\+\)G/\1E+9/g' -e 's/\([0-9]\+\)T/\1E+12/g' transistors_raw.csv > transistors.csv # removes the not-fixed copy clean: rm transistors_raw.csv Modify the scp-command to use * The username and the correct mikroserver in the scp-command * change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/ * change the local folder where you want your copy to be placed, default is /home/$user/ Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder. == Open the file in Libre Office == The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image: [[File:Csv_import_libreoffice.png | 500px]] == Troubleshooting == For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]] [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 5c76ee54ec20cf9f2375ddd40fc30fc17832b74a 0 614 2908 2759 2024-05-30T11:52:52Z Nfyku 4 wikitext text/x-wiki = Setup of connection to mikroservers= This setup process will allow you to connect to the mikroservers with one command without typing any password or long host names. == SSH key == To login to the server without having to type in your password every time, we can use SSH key pairs. The public key is stored on the server, and you have your private key stored on the UiB login server. To generate a key, type into the terminal ssh-keygen This will generate the files id_rsa and id_rsa.pub in the folder ~/.ssh, where the latter is the public key that needs to be stored on the server. Copy the key with your identity to any of the mikroservers (since the user environment is shared for each server, this will give you access to all the servers). You can do this manually, but the easiest way is to use the ssh-copy-id utility. NB: Replace USERNAME with your username and mikroserver with the full name of your preferred mikroserver. ssh-copy-id USERNAME@mikroserver You will be prompted your password. After the key is copied, you should be able to login with "ssh USERNAME@mikroserver" without having to enter your password. == Connection aliases == Now that you can login without typing your password, it is also convenient to set up aliases for the servers to connect quicker. To do this, type "gedit ~/.ssh/config" in the terminal. This will open up an empty file, and here you can store shorthand names and specific SSH settings for the connection, such as your username. Host mikroserver HostName mikroserver User USERNAME Port 22 ForwardX11 yes ForwardX11Trusted yes Copy and repeat this for each server in the same file, remembering to change the hostname to the full name of the corresponding mikroserver for each entry. ForwardX11 allows you to launch software on the server itself, while displaying the GUI remotely to the lab PC. After saving the file, you should be able to simply write "ssh mikroserver" in the terminal to login to the chosen mikroserver. Note: If you are attempting to do this step remotely from the UiB login server you need to use a terminal-based editor like Vim, or connect to the login-server with ssh -Y USERNAME@login.uib.no to enable the use of graphical editors such as gedit. == Automatic sourcing == There are two main files of sourcing scripts in a Linux environment. One is the file .bashrc, and the other is the file .profile. The difference in these is that the contents of .profile is executed upon login, and .bashrc is executed every time you access the terminal. .bashrc is not sourced to the system by itself upon login, so we need to source .bashrc in .profile manually to use it. This must be done after connecting to one of the mikroservers. echo "source ~/.bashrc" >> ~/.profile Scripts can be sourced either within .profile or .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually every time. == Accessing the lab software remotely on your private PC == You do not need to set up a VPN to access the lab software from home. By connecting to the mikroservers through the UiB loginserver with X11 forwarding enabled, you can run the software from any network. You can do this directly on Linux/macOS by using SSH in the bash terminal. For Windows, you will need to download the X server software [https://sourceforge.net/projects/xming/ Xming] to enable X11 forwarding. This install comes with PuTTY, an SSH client we will use to connect to the Linux based UiB server. === Linux/macOS === The process is the same for both Linux and macOS, except that for macOS you first have to install the X11 server software named [https://www.xquartz.org/ XQuartz]. Then, simply connect to the login server by typing ssh -Y USERNAME@login.uib.no The -Y enables trusted X11 forwarding. From here, you can "ssh mikroserver" just as you would from the lab PC and run software. The steps described above (SSH keys and config files) can be repeated on your personal Linux/macOS PC to simplify connecting to the UiB loginserver. On Linux, the configuration file is located in "~/.ssh/config" just as on the server, while on macOS it is located in "/private/etc/ssh/ssh_config". === Windows === Install Xming and make sure you include PuTTY in the install. Run Xming. It will start minimized, and does not require any setup. When first opening PuTTY, you will be presented with this configuration menu. Fill in the hostname "login.uib.no", but don't connect yet. [[File:Puttylogin.png]] Navigate to Connection -> SSH -> X11, and check Enable X11 forwarding, and type in "localhost:0.0" as X display location. [[File:Puttyx11.png]] Return to Session, and make sure connection type is set to SSH. Press "Default Settings" and Save to save this configuration for later. Press Open to connect to the server. Enter your username and password, and now you should be in the Linux terminal for the UiB login server. Try to run "gedit" to confirm that you can run a graphical interface. From here you can ssh to the mikroservers and launch software as on the lab computer. Confirm by running gedit on the mikroserver as well to see that you can tunnel X11 through the login server correctly. == Add mikroserver as a folder on your pc == Open up your home folder in Linux and in the bottom left corner click "Connect to Server" as shown in this picture: [[File:ConnectToServer.png|thumbnail]] as server address type: [sftp://mikroserver3/home/USERNAME sftp://mikroserver/home/USERNAME] to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]]) To store this connection, right click the "mikroserver"-folder and click "Add Bookmark". The next time you just click the bookmark to open it. === Alternative way using scp/secure copy=== If for some reason the above doesn’t work you can try this: * connect to your mikroserver * locate the file you want to copy. i.e /home/USERNAME/picture.jpg * type this command scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to * this will copy the file to your home folder on any UiB machine * To copy a folder scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to == Troubleshooting == * Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work * You have to be either connected to the UiB loginserver or run the commands via the computers in the lab to be able to connect to the mikroservers * If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc * Make sure you have replaced all the instances of USERNAME with your usename, i.e "abc0123" [[Category:Mikroelektronikk]] 73a8f02fb5a4f0a5a2780a29f2c5d8548cc8ed9c 0 461 2909 2710 2024-05-30T11:54:37Z Nfyku 4 wikitext text/x-wiki =Cadence design with TSMC 130nm process= This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process. Here is the outline of the analog IC design flow: # Schematic capture (Cadence tool) # Netlist extraction from schematic # Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations) # Layout using Cadence # Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool) ==Setup of Cadence== To start virtuoso one must first connect to the chosen mikroserver ssh -X mikroserver '''First''' time you should add the following line to your cds.lib-file by running this command: mkdir ~/tsmc echo "DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf" > ~/tsmc/cds.lib Then ('''each time''') run these commands to set up Cadence source /eda/cadence/2023-24/scripts/analog_flow.sh source /eda/cadence/eda_general_init.sh Virtuoso Mixed Signal Design Environment is started by issuing this command: virtuoso & === Troubleshooting === * Make sure you source the script from the correct year. For example 2023-24 and not 2016-17 * Make sure you are connected the the right mikroserver * Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/tsmc/') == Getting started == In the log window, choose "File > New > Library". In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev". After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked. Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture: [[File:virtuoso_schematic_editor.png|400px]] ==Entering the design== To create the inverter design, do the following: # Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button. # To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input. # To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option). # To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two. # To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard. # To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output. # To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3. # To check and save the schematic, press 'x' or click the "Check and save" icon. # If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing. ==Simulating the design== # Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up. # Choose "Create > Test..." select the cell to simulate. # Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output. # Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3. [[File:select_comp_parameter.png|300px]] The analog environment should now look like this: [[File:analog_env_2.png|500px]] Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this: [[File:plot_output_dc.png|600px]] To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state". ==Generating a Symbol== Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology). Select the schematic tab and choose "Create -> Create Cellview -> From Cellview". Press OK in the dialog that occurs. The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur. Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol [[File:symbol.png|400px]] Save it by clicking the "Save and check" symbol or pressing 'shift+X'. [[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] 2ef22a662ea7a4bc6cd13e3f6435cbf982d1597f 0 278 2911 2745 2024-06-10T08:56:50Z Nfyku 4 /* Nettressurser */ wikitext text/x-wiki == Fagressurser for bruk i PHYS321 == === Fagbøker === * [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits] === Nettressurser === * [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators] * [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register] * [https://robey.lag.net/2012/11/14/how-to-add-numbers-2.html How to add numbers (part 2)] ==== Cadence tutorials ==== * [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel] * [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube] * [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube] * [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube] ==== Digilent Nexys 4 ==== * [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence] * [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started] * [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc] * [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center] ==== Using Vivado ==== * [[Install Vivado 2015.4 with free license]] * [[VGA controller VHDL code]] * [[Nexys4_Master.xdc]] * [[Using the VGA controller with block ram generator and clock wizard]] === Gamle øvingsoppgaver === [[Øvingsoppgaver PHYS321]] [[Category:Mikroelektronikk]] 35bbce4bc134c2da7a0830fcf7672c521af7aa8b 0 202 2912 2764 2024-10-02T11:47:54Z Nfyku 4 Added some lectures in Tutorials and lectures wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] ==== Tutorials and lectures ==== * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] * [https://www.youtube.com/playlist?list=PLc7Gz02Znph-c2-ssFpRrzYwbzplXfXUT New Analog Circuit Design (By Prof. Ali Hajimiri, Caltech)] * [https://www.khanacademy.org/science/electrical-engineering Electrical engineering (Khan Academy)] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process] * [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm] * [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory] * [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication] * [https://youtu.be/ApWOf6J858Y Integrated circuit scaling to 10 nm and beyond - Mark Bohr, Intel Senior Fellow] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] c8b962dc1dd597e4e7ed5627cd497e17cf3d9d0f 2913 2912 2024-10-02T11:48:20Z Nfyku 4 wikitext text/x-wiki == Fagressurser for bruk i PHYS222 og PHYS223 == === Fagbøker === * [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective] * [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition] === Tutorials and lectures === * [http://www.electronics-tutorials.ws Basic Electronics Tutorials] * [https://www.youtube.com/playlist?list=PLc7Gz02Znph-c2-ssFpRrzYwbzplXfXUT New Analog Circuit Design (By Prof. Ali Hajimiri, Caltech)] * [https://www.khanacademy.org/science/electrical-engineering Electrical engineering (Khan Academy)] === Noise === * [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors] * [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation] * [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth] === Halvlederfysikk === * [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?] * [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere] * [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets] * [http://pveducation.org/ Photovoltaic Education Network] * [http://www.semi1source.com/glossary/ Semiconductor Glossary] === Prosessteknologi === * [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours] * [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process] * [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm] * [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory] * [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication] * [https://youtu.be/ApWOf6J858Y Integrated circuit scaling to 10 nm and beyond - Mark Bohr, Intel Senior Fellow] * [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive] === Logical effort === * [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia] === Matlab/Maple === Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler: * [[Symbolsk løsning av nodeligninger med Matlab]] * [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations] === Kretssimulering === [[ Eksempler/Oppgaver ]] ==== AIM-Spice ==== AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results. SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses. [http://www.aimspice.com/download.html Download a free student version] ==== LTspice ==== LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models. [http://www.linear.com/designtools/software/switchercad.jsp Download LTspice] [[Category:Mikroelektronikk]] 4e3049300ca33712001a32546b948ce309a5d4e1